• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (6)

1 localhost commented Permalink

Welcome aboard!FYI, that third pseudo-message above should probably be using POST instead of GET (I assume that's a typo).Also, I personally consider Servlets to be a fine "RESTful API" for Java, though you're correct that using them doesn't necessarily mean you're RESTful. On the other hand, more than any other Java API out there, it does a pretty good job at constraining the developer to using REST's constraints.

2 localhost commented Permalink

Mark (distobj): Thanks for your comments.I did intend for the verb to create a new order to be GET, so that's not a typo; but it may be bad REST code! My reasoning is that I don't just want to create an order, I also want to return it to the client, so that seems like a getter, thus GET. My understanding is that PUT/POST and DELETE verbs don't return much data, just the results of the action they perform; so if you want data returned use GET. Is this not consistent with the REST conventions?Also, do you know what the difference is between PUT and POST? I notice that you said that my action should be a POST; why not a PUT?I hadn't thought about Servlet being the only Java API you need for REST, but that makes sense, and that's consistent with the "REST is just using the Web as a Web service" philosophy.Thanks for your input.

3 localhost commented Permalink

"My reasoning is that I don't just want to create an order, I also want to return it to the client, so that seems like a getter, thus GET. My understanding is that PUT/POST and DELETE verbs don't return much data, just the results of the action they perform; so if you want data returned use GET. Is this not consistent with the REST conventions?"No it is not, primarily because GET should be free of side-effects:http://www.w3.org/2001/tag/doc/whenToUseGet.htmlA safer interaction for creating a new order would be:POST http://example.com/order -- creates a new order with a server-generated ID and returns its URI (e.g., http://example.com/order/321)GET http://example.com/order/321 -- returns info about order #321

4 localhost commented Permalink

"I'm still not clear on the difference between PUT and POST. Notice that I now POST to create an order and PUT to update it. Is this correct?"It could be, depending on the semantics of your application. If the server is responsible for generating unique identifiers for new orders, then yes, that is correct. However, if the client is able to generate unique identifiers (e.g., UUIDs) and can therefore mint its own URIs, then it could use PUT to create a new order.Here's what the HTTP 1.1 spec has to say,"The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource."http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6So, when a client uses PUT it is declaring that it knows the URI of the resource that it's sending. When it uses POST it only knows the URI of a resource that can handle the content it's sending and that the server should do whatever is appropriate. That's why in a POST response, the server returns the URI of the new resource -- so that the client knows where it ended up."Not to get grouchy here, but REST is supposed to be simpler than SOAP. Seems like when the verbs are somewhat unclear like this, and when it takes multiple commands and round trips to perform one logical action, it takes away from the simplicity."Is what you're describing really one logical action? As an analogy, would you expect your RDBMS to automatically perform a SELECT after an INSERT is executed?

5 localhost commented Permalink

"My reasoning is that I don't just want to create an order, I also want to return it to the client, so that seems like a getter, thus GET. My understanding is that PUT/POST and DELETE verbs don't return much data, just the results of the action they perform; so if you want data returned use GET. Is this not consistent with the REST conventions?"REST doesn't say much about that, but it's not consistent with the use of HTTP, no. All HTTP responses can have data in them, so that's no problem. The reason POST is appropriate is primarily because its meant to accept data for processing, while GET is for queries."Also, do you know what the difference is between PUT and POST? I notice that you said that my action should be a POST; why not a PUT?"PUT is for setting the state of something. As your blog post says, you'd use it if you wanted to edit the state of the order.You also said;"Accordingly, I've changed the singe GET command that I imagined would create and return an order to two commands: a POST to create the order, which returns the URL for the order, and then a GET to retrieve the order."You can get the best of both worlds (URI & data in the response); just use the 201 (created) response and indicate the URI on the Location header, but also include the order document in the response.

6 localhost commented Permalink

Oops, forgot a comment.."Not to get grouchy here, but REST is supposed to be simpler than SOAP. Seems like when the verbs are somewhat unclear like this, and when it takes multiple commands and round trips to perform one logical action, it takes away from the simplicity."It can certainly reduce the efficiency, but the simplicity remains intact IMO.

Add a Comment Add a Comment