So there seems to be a lot of angry HN comments about this, but it makes sense to me. There are few RPC mechanisms that I’m aware of that make this read only vs mutable distinction. With different calling conventions no less.
Other than some abstract purity argument, is all post all the time a real problem? Like if http only supported post, would you be unable to build an application using it?
I disagree and I think PUT and DELETE aren’t necessary. You want one cacheable read operation (GET). Everything else is POST. Idempotency is usually so application specific that I don’t think verbs capture it well enough.
Oh, sure - the way you achieve idempotency is going to be application-specific.
But once you’ve built something with idempotent actions, it can be useful to indicate which actions are idempotent (without observers having to know anything about your application). That’s where PUT and DELETE are valuable.
That’s a fair point, but how does one then deal with POST failure? A reliable distributed system needs to retry, it can’t just punt at the first sign of trouble.
http/POST seems like the wrong layer to introduce idempotency, since it knows nothing about the application. I’m not sure what the end to end principle says here, but I think it’s probably embedding more state in your requests to enable the server to detect stale operations.
That’s a fair point, but how does one then deal with POST failure?
The same way you deal with a failed RPC call: it depends on what you were attempting. The nice thing about GET/PUT/DELETE is that you don’t need to know what you were attempting to know that it’s safe to retry.
I think REST has problems and should rightfully be criticized, but this post reeks of “I don’t understand any of that, I want to use operation-centric APIs, let’s go back to ad-hoc XML-RPC”.
All the rhetoric questions in the post are very well addressed in Fieldings Dissertation about REST, I expect current additions to the discussion to be a bit more sophisticated.
Agree. Particularly when it comes to stuff like “where does a particular error code come from? Client? Your app? CONFUSING!!1!1” Well, that’s up to your application design - and whether or not you want to prioritise (perhaps over-) simplification over the ability to track down errors accurately and efficiently has no impact on the fact that I don’t, thanks very much.
Most importantly for me it seems to be polarising unnecessarily - it’s quite possible to take the REST approach as a set of guiding principles which actually help structure your system without getting so dogmatic about a perceived “canonical” or “right” way to do things that it ham-strings you.
Real-world “REST APIs” aren’t that sophisticated though. No-one follows the dissertation.
I never understood the hate for SOAP. Well, other than namespacing and performance issues and terrible XML-parsing libraries and… ok. But the idea doesn’t seem fundamentally flawed.
These days I use Thrift wherever I can get away with it.
I didn’t ask for following the dissertation, but that it sets the lower bar for the discussion and all points the author raised are well-addressed in the dissertation.
On top of that, I’ve implemented multiple hypermedia-driven REST APIs in my career and they all worked quite well. The frontends end up really simple because the backend tells them what’s possible.
The hate for SOAP is simple: it’s a very bad implementation of RPC. RPC in itself isn’t bad, e.g. APIs for a cloud service where most actions are actually actions and not data are better of using RPC style, I hate working with their REST interfaces.
REST is a very good idea if you take a data-centric approach and the HTTP/Hyperlink vocabulary is made just for that.
I cannot edit, but I’ve go a better picture here: Basically, the author roots for replacing “GET /foo” by “POST /getFoo”, basically just moving the verb and introducing the repetition they lament just at another place. It moves structure from the protocol into a more generic structure.
But you don’t have to repeat it if it’s not part of the operation.
I think it’s warranted in this case because the HTTP verb set doesn’t cover all the cases. It reminds me a bit of the “falsehoods programmers believe about addresses/names” posts - if you don’t actually need to use the structure, then it’s best to just give the user a free-text field for their name/address.
My interpretation of the post is observing that limiting yourself to a few verbs and only allowing noun’s to change just doesn’t make much sense. I think I agree with that.
When talking about just data, HTTP covers all important cases, in a standardized way that subsequent components can work with and implement. Freedom of vocabulary would lead to a rippling effect, making all subsequent systems harder.
And that’s exactly the way Fielding interprets architecture in his dissertation: as a voluntary set of constraints ensuring that interacting systems speak a common vocabulary. Implemented properly, you can reap a lot of benefits from that. Yes, the constraint is a feature. Fielding would directly disagree with you that limiting yourself is wrong.
The issue is: given a blank space only constrained by your wire speed and the halting problem, how do you create a system you can reason about? By limiting yourself. The limitations of REST are a virtue, not a problem. If they are the right virtue at that point, is another question. But if fit the dominant model of web applications before the mobile era very well.
The often bad and sloppy implementation of architectural styles is something to take seriously, but doesn’t make an architectural style bad.
REST has extreme drawbacks for some applications, there are for example many where an event stream fits much better, which doesn’t really work for REST.
The focus on URL structure indicates that the author doesn’t actually know what REST is. There’s nothing unRESTful about GET /customer/getOrder?customerID=33245&orderID=8769.
REST isn’t RPC, and judging it by how good it is at RPC completely misses the point.
This seems like a common point of confusion. I mostly follow web development from the sidelines. I see two arguments frequently.
“That’s not RESTful! You’re breaking the web!”
“You’re not supposed to use REST for that!”
It seems, roughly, that everybody using REST shouldn’t and everybody not should. I don’t have particularly strong opinions either way, I’m just going to do what I think makes sense, but this seems like a topic one needs to read like ten years' worth of scattered blog posts to comprehend.
For example, this article seems like a continuation of previous discussion that Dropbox was committing a crime against humanity for using POST instead of GET for large queries, but I’m not sure if that’s deliberate or happenstance.
Sure, online developer culture has a huge problem with nuance, with understanding things before taking an opinion on them, and with examining things as sets of tradeoffs to be selected rather than ideals to be followed. This is true on each side of every contentious issue.
(I think you’re being uncharitable about the Dropbox post though. Even if you disagree with how the author weights the tradeoffs, they clearly understand them, and aren’t treating Dropbox’s use of POST like a calamity.)
I was perhaps comingling some of the more rabid online commentary with that blog post, but addressing specifically the post. Starts off acknowledging some tradeoffs, but then veers off into what I’d almost consider a parody with the POST and GET alternative. Complete with “Don’t break the web!”. As if anybody is going to be long term bookmarking a dropbox /delta link.
I agree that verbs besides GET and POST aren’t useful. I found out that SPACEJUMP was a verb in the HTTP spec many years ago. It’s all not nearly as well thought out as people would like to believe.
So there seems to be a lot of angry HN comments about this, but it makes sense to me. There are few RPC mechanisms that I’m aware of that make this read only vs mutable distinction. With different calling conventions no less.
Other than some abstract purity argument, is all post all the time a real problem? Like if http only supported post, would you be unable to build an application using it?
Cachable resources are nice for performance reasons. That’s about it.
And idempotency; every component of the system knows that it’s safe to retry a GET (or a PUT, or a DELETE).
I disagree and I think PUT and DELETE aren’t necessary. You want one cacheable read operation (GET). Everything else is POST. Idempotency is usually so application specific that I don’t think verbs capture it well enough.
How so?
How would you map Operational Transforms on to HTTP verbs? Dropbox uses these algorithms in their Datastore API and here’s how they map it to HTTP.
Oh, sure - the way you achieve idempotency is going to be application-specific.
But once you’ve built something with idempotent actions, it can be useful to indicate which actions are idempotent (without observers having to know anything about your application). That’s where PUT and DELETE are valuable.
That’s a fair point, but how does one then deal with POST failure? A reliable distributed system needs to retry, it can’t just punt at the first sign of trouble.
http/POST seems like the wrong layer to introduce idempotency, since it knows nothing about the application. I’m not sure what the end to end principle says here, but I think it’s probably embedding more state in your requests to enable the server to detect stale operations.
The same way you deal with a failed RPC call: it depends on what you were attempting. The nice thing about GET/PUT/DELETE is that you don’t need to know what you were attempting to know that it’s safe to retry.
I think REST has problems and should rightfully be criticized, but this post reeks of “I don’t understand any of that, I want to use operation-centric APIs, let’s go back to ad-hoc XML-RPC”.
All the rhetoric questions in the post are very well addressed in Fieldings Dissertation about REST, I expect current additions to the discussion to be a bit more sophisticated.
Agree. Particularly when it comes to stuff like “where does a particular error code come from? Client? Your app? CONFUSING!!1!1” Well, that’s up to your application design - and whether or not you want to prioritise (perhaps over-) simplification over the ability to track down errors accurately and efficiently has no impact on the fact that I don’t, thanks very much.
Most importantly for me it seems to be polarising unnecessarily - it’s quite possible to take the REST approach as a set of guiding principles which actually help structure your system without getting so dogmatic about a perceived “canonical” or “right” way to do things that it ham-strings you.
Real-world “REST APIs” aren’t that sophisticated though. No-one follows the dissertation.
I never understood the hate for SOAP. Well, other than namespacing and performance issues and terrible XML-parsing libraries and… ok. But the idea doesn’t seem fundamentally flawed.
These days I use Thrift wherever I can get away with it.
I didn’t ask for following the dissertation, but that it sets the lower bar for the discussion and all points the author raised are well-addressed in the dissertation.
On top of that, I’ve implemented multiple hypermedia-driven REST APIs in my career and they all worked quite well. The frontends end up really simple because the backend tells them what’s possible.
The hate for SOAP is simple: it’s a very bad implementation of RPC. RPC in itself isn’t bad, e.g. APIs for a cloud service where most actions are actually actions and not data are better of using RPC style, I hate working with their REST interfaces.
REST is a very good idea if you take a data-centric approach and the HTTP/Hyperlink vocabulary is made just for that.
I cannot edit, but I’ve go a better picture here: Basically, the author roots for replacing “GET /foo” by “POST /getFoo”, basically just moving the verb and introducing the repetition they lament just at another place. It moves structure from the protocol into a more generic structure.
But you don’t have to repeat it if it’s not part of the operation.
I think it’s warranted in this case because the HTTP verb set doesn’t cover all the cases. It reminds me a bit of the “falsehoods programmers believe about addresses/names” posts - if you don’t actually need to use the structure, then it’s best to just give the user a free-text field for their name/address.
My interpretation of the post is observing that limiting yourself to a few verbs and only allowing noun’s to change just doesn’t make much sense. I think I agree with that.
When talking about just data, HTTP covers all important cases, in a standardized way that subsequent components can work with and implement. Freedom of vocabulary would lead to a rippling effect, making all subsequent systems harder.
And that’s exactly the way Fielding interprets architecture in his dissertation: as a voluntary set of constraints ensuring that interacting systems speak a common vocabulary. Implemented properly, you can reap a lot of benefits from that. Yes, the constraint is a feature. Fielding would directly disagree with you that limiting yourself is wrong.
The issue is: given a blank space only constrained by your wire speed and the halting problem, how do you create a system you can reason about? By limiting yourself. The limitations of REST are a virtue, not a problem. If they are the right virtue at that point, is another question. But if fit the dominant model of web applications before the mobile era very well.
The often bad and sloppy implementation of architectural styles is something to take seriously, but doesn’t make an architectural style bad.
REST has extreme drawbacks for some applications, there are for example many where an event stream fits much better, which doesn’t really work for REST.
The focus on URL structure indicates that the author doesn’t actually know what REST is. There’s nothing unRESTful about
GET /customer/getOrder?customerID=33245&orderID=8769.REST isn’t RPC, and judging it by how good it is at RPC completely misses the point.
This seems like a common point of confusion. I mostly follow web development from the sidelines. I see two arguments frequently.
“That’s not RESTful! You’re breaking the web!”
“You’re not supposed to use REST for that!”
It seems, roughly, that everybody using REST shouldn’t and everybody not should. I don’t have particularly strong opinions either way, I’m just going to do what I think makes sense, but this seems like a topic one needs to read like ten years' worth of scattered blog posts to comprehend.
For example, this article seems like a continuation of previous discussion that Dropbox was committing a crime against humanity for using POST instead of GET for large queries, but I’m not sure if that’s deliberate or happenstance.
Sure, online developer culture has a huge problem with nuance, with understanding things before taking an opinion on them, and with examining things as sets of tradeoffs to be selected rather than ideals to be followed. This is true on each side of every contentious issue.
(I think you’re being uncharitable about the Dropbox post though. Even if you disagree with how the author weights the tradeoffs, they clearly understand them, and aren’t treating Dropbox’s use of POST like a calamity.)
I was perhaps comingling some of the more rabid online commentary with that blog post, but addressing specifically the post. Starts off acknowledging some tradeoffs, but then veers off into what I’d almost consider a parody with the POST and GET alternative. Complete with “Don’t break the web!”. As if anybody is going to be long term bookmarking a dropbox /delta link.
I agree that verbs besides GET and POST aren’t useful. I found out that SPACEJUMP was a verb in the HTTP spec many years ago. It’s all not nearly as well thought out as people would like to believe.
I was waiting for him to introduce WSDL and WS-*, but he didn’t get that far. Maybe next time.