81–90 of 124 posts
I prefer to call my APIs RESTish. That way, I can avoid never ending debates about whether some particular feature of my API conforms to REST.
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…
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?
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 transfer", but just about using URLs to request operations from server.
The original REST idea of using HTTP error codes and forbidding application to create its own error classes and error reporting convention just doesn't work. HTTP errors only meaningful for HTTP - a transfer protocol, not for arbitrary application.
The point of using different HTTP verbs - chaching. Don't do
GET /deleteItem?itemId=456
So, I use HTTP URLs to communicate with server, and don't care to follow REST dogmas. It's more similar to what article calls "RPC" (actually RPC is more general term, in particular including SOAP).
I would argue REST wins on beauty, because it continues to follow the intent of a URL -- you can locate the resource based on the URL. In RPC, the query parameters break the URL concept a bit by including location data in the parameters rather than in the path.
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…
I prefer to call my APIs RESTish. That way, I can avoid never ending debates about whether some particular feature of my API conforms to REST.
In the end we made the API as REST(ful|ish) as possible and in places that we needed to be a little more flexible we tried to keep close to common practices. I think as long as your API is sane, easy to use, well documented (and tested), then users aren't going to care whether or not it is 100% RESTful.
Earlier quoted context omitted.
there is nothing in the specification of the PUT verb that indicates it is meant only for complete replacement of an existing resource. in fact, the RFC specifically has a section describing the semantics of creation using PUT. therefore, either your stance is trivially falsified, or you were replying to me out of context, which is intellectually dishonest. https://tools.ietf.org/html/rfc7231#section-4.3.4
> 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…
I generally use a pattern like: GET /api/resource POST /api/resource/action Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.
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.
E.g. sending money, transfer item, bulk modify A while update B, etc.