91–100 of 124 posts
REST as "representational state transfer" is a boolshit. The real reason it is popular - it allows to communicate via HTTP, just URLs everyone understands and many tools available, even web browser can be used. If you remember SOAP - the crazy approach to web services promoted before REST, you understand the difference REST made. The same way AJAX is not about XML, REST for me is not about "representational state tra…
One point that didn't get addressed in this article is the use of HTTP status codes to indicate the result of a request. REST encourages proper use of status codes – 404 for a missing resource, 422 for invalid data, 201 for successful resource creation, etc. – further enhancing the predictability of the API. How does RPC handle status codes?
Eh, sorta. Send an invalid body, say an unavailable product ID, or an invalid quantity. What error will you return? HTTP codes and REST might make sense for some simple scenarios (like managing files), but it breaks down fast otherwise. Shoehorning everything into the few codes HTTP has seems pointless.
In this case the client has sent an invalid request so the response should be 400 Bad Request or 422 Invalid Data, with details of the error in the response body.
One point that didn't get addressed in this article is the use of HTTP status codes to indicate the result of a request. REST encourages proper use of status codes – 404 for a missing resource, 422 for invalid data, 201 for successful resource creation, etc. – further enhancing the predictability of the API. How does RPC handle status codes?
Eh, sorta. Send an invalid body, say an unavailable product ID, or an invalid quantity. What error will you return? HTTP codes and REST might make sense for some simple scenarios (like managing files), but it breaks down fast otherwise. Shoehorning everything into the few codes HTTP has seems pointless.
The pet peeve issue I have with RPC/HTTP APIs is that people keep reinventing HTTP on top of it, only badly (at which point they may as well use RPC/TCP). That's why I like REST/HTTP, because I can "reuse things" when the problem model fits well within that tool (and it very often does). If REST/HTTP becomes a constraint instead of an asset, then maybe one should not use either REST or HTTP, and I'm fine with it because that was not the tool for the job.
This is a tool, not a religion.
Earlier quoted context omitted.
Why would you do this? It makes no sense. By (mostly) adhering to REST patterns you get so much stuff for free. Other developers can quickly get up to speed quickly. Client libraries are easier to write. Things like Ember Data work out of the box. I agree that every now and then doing a POST to /logout is easier than doing a DELETE /access_token/23, but a consistent API is far more worth it.
Because not every operation is CURD against one resource. E.g. sending money, transfer item, bulk modify A while update B, etc.
Earlier quoted context omitted.
> The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. So PUT either creates or replaces a resource. Definition of replaced: > 1. take the place of. Source: https://www.google.com.au/search?q=define%3A+replaced It is pretty clear to me that the spec says PUT completely replaces the state of a resource…
so since the post I replied to said that POST is for create, and PUT is for complete replacement, and you just indicated that PUT can be used in ways that the OP did not, and I objected to the OP's prescriptivism, you agree with me despite your stance of arguing with me about it.
It seems to be that many of the comments on this and other API posts recently are by people who have never had to integrate with some else's "mostly REST but only when it suits me" API. If the API you are writing has these features: * you are the consumer as well as the author. * no other developer is ever going to need to understand it. * don't care about server/proxy/library support. by all means don't bother with…
Let's say you have to integrate with my API that uses GET /user?id=1 instead of /user/1 , How have I made your life worse? Is it going to cost you any extra time at all to code it up?
It seems to be that many of the comments on this and other API posts recently are by people who have never had to integrate with some else's "mostly REST but only when it suits me" API. If the API you are writing has these features: * you are the consumer as well as the author. * no other developer is ever going to need to understand it. * don't care about server/proxy/library support. by all means don't bother with…
Let's say you have to integrate with my API that uses GET /user?id=1 instead of /user/1 , How have I made your life worse? Is it going to cost you any extra time at all to code it up?
> The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource . . .
source: https://tools.ietf.org/html/rfc3986#section-3.4
With a caveat, you will note the "non-hierarchical data" bit.
It means that this:
GET /user/1/groups
GET /user?id=1&groups
Why? The spec doesn't say of course but at a guess I'd say because there is already a hierarchical data format in URLs, the path. This assumption is build into every web framework & language I've ever used, with query strings being passed as unordered dictionaries.
As you suggest the convention is to only use query strings as search parameters and the like. Personally I think conventions are useful to follow, especially when they don't cost you anything like the one we're talking about.
The Richardson Maturity Model, as explained by Martin Fowler, is the only explanation of the benefits of REST that has ever made sense to me: http://martinfowler.com/articles/richardsonMaturityModel.htm... And for what it's worth, I've only found value in levels 1 and 2, not level 3. Also, this talk by DHH helped me understand how to organize an API by creating more nouns with a restricted set of verbs, instead of pr…
Another thing that struck me strange about the article is showing the RPC urls. When I was using Thrift, I never needed to think about URLs. I just needed to make sure that I was calling methods correctly.
I think RPCs are a good fit for organizations looking for a way for their service based architecture to communicate. I don't really like exposing RPCs as a public API or for web clients to interact with.