4 ms·

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 m

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 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 because it's not guaranteed to reach the sever. Use POST instead. 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).

hessenwolf 11y ago
Feel free to expand those explanations... :)
- avodonosov 11y ago
  Not much to add. The REST culture gives us some regularity. If we read github API, or google API or facebook API, we know what to expect - that they will use GET to retrieve an object, DELETE to delete an object and so on. It's good there is a convention helping to study new things. Another good property of REST culture - it prevents people from building thick layers on top of HTTP. While not everything can fit into HTTP (at least error reporting, in my opinion; HTTP error codes are not enough), this culture helps to keep APIs simple.
  - collyw 11y ago
    Other than the verbs used, there isn't very much regularity. Try plugging a back end REST API into a front end framework. In my experience you always need an extra library.
deleted 11y ago
[deleted]
Nemcue 11y ago
"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." To be fair, that's kind of like saying AJAX isn't about asynchronous requests. Fielding doesn't agree with you. But that's your interpretation, and that's fine I guess. The point with Hypermedia APIs however is the "representational state transfer" via defined relationships between the resources.
tete 11y ago
> The point of using different HTTP verbs - chaching. Don't do > GET /deleteItem?itemId=456 Yes and no. Use DELETE for delete basically for that reason, but the statement that there are different verbs for caching is wrong. That's what a variety of Headers are there for. The fact that GET is in many cases cached simply is that a GET isn't there for state changes, so it doesn't matter whether it reaches the server (headers are there to tell whether it should). That's for how things are meant to be, but I agree that it often isn't like that. Properties of HTTP were (ab)used for other things. I think that's a mixture of not understanding HTTP (in other words, not having read RFCs) and of course practical reasons. We can see that a lot in the web in general. A lot of things get used in different, often completely wrong (as in standards breaking ways) and so things are not really coherent. That includes HTTP, HTML, CSS, ... and that's why new versions of these standards and up having a rather strong break. Caching is actually a great example if you look at HTTP/1 vs HTTP/2. But you may also be look at tags like <i> or <b> in HTML. They started out for styling, then they were discouraged and now they have a more semantic reasoning (see HTML 5's definition). Doesn't mean that how it is used a lot is exactly bad. It actually just shows that the original ideas, the REST dogmas, etc. maybe don't fit and people use the best from RPC and REST. HTTP is used really universally, which also explains why there are things like WebSockets which barely fit with the original ideas and concepts of what HTTP is. On the other hand it worked extremely well, when you look at its popularity.

hessenwolf 11y ago

Feel free to expand those explanations... :)

avodonosov 11y ago
Not much to add. The REST culture gives us some regularity. If we read github API, or google API or facebook API, we know what to expect - that they will use GET to retrieve an object, DELETE to delete an object and so on. It's good there is a convention helping to study new things. Another good property of REST culture - it prevents people from building thick layers on top of HTTP. While not everything can fit into HTTP (at least error reporting, in my opinion; HTTP error codes are not enough), this culture helps to keep APIs simple.
- collyw 11y ago
  Other than the verbs used, there isn't very much regularity. Try plugging a back end REST API into a front end framework. In my experience you always need an extra library.

deleted 11y ago

[deleted]

Nemcue 11y ago

"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." To be fair, that's kind of like saying AJAX isn't about asynchronous requests. Fielding doesn't agree with you. But that's your interpretation, and that's fine I guess. The point with Hypermedia APIs however is the "representational state transfer" via defined relationships between the resources.

tete 11y ago

> The point of using different HTTP verbs - chaching. Don't do > GET /deleteItem?itemId=456 Yes and no. Use DELETE for delete basically for that reason, but the statement that there are different verbs for caching is wrong. That's what a variety of Headers are there for. The fact that GET is in many cases cached simply is that a GET isn't there for state changes, so it doesn't matter whether it reaches the server (headers are there to tell whether it should). That's for how things are meant to be, but I agree that it often isn't like that. Properties of HTTP were (ab)used for other things. I think that's a mixture of not understanding HTTP (in other words, not having read RFCs) and of course practical reasons. We can see that a lot in the web in general. A lot of things get used in different, often completely wrong (as in standards breaking ways) and so things are not really coherent. That includes HTTP, HTML, CSS, ... and that's why new versions of these standards and up having a rather strong break. Caching is actually a great example if you look at HTTP/1 vs HTTP/2. But you may also be look at tags like <i> or <b> in HTML. They started out for styling, then they were discouraged and now they have a more semantic reasoning (see HTML 5's definition). Doesn't mean that how it is used a lot is exactly bad. It actually just shows that the original ideas, the REST dogmas, etc. maybe don't fit and people use the best from RPC and REST. HTTP is used really universally, which also explains why there are things like WebSockets which barely fit with the original ideas and concepts of what HTTP is. On the other hand it worked extremely well, when you look at its popularity.