Microsoft-stack developer doesn't understand how HTTP works. Film at eleven.
Who Cares about GET vs. POST? NoREST
41–50 of 106 posts
Re: Who Cares about GET vs. POST? NoREST
#42REST is good, better than RPC, SOAP... finally people can understand and use APIs easily and happily. The URL /customer/33245/order/8769 is perfect, looks like a directory path and reflect the relationship between the entities. Arguing about the best url, status code and best verb is the irrelevant part in REST. Why can't people just do whatever it works for the users while respecting the standards when they can ?!
I think you've inadvertently put your figure on the part that really matters. REST is worse than SOAP or something like Thrift for discoverability, worse for ease of use, worse for practically every criterion you could think about. The one thing it does right is being easy to explore with a web browser.
So optimize for that. Make it easy for a developer to look at your API with a web browser. This means simple URLs. It may mean a limited form of HATEOAS, in terms of providing links to the next things.
But it absolutely doesn't mean using HTTP status codes to convey important information. It doesn't mean using content negotiation for API versioning. It doesn't mean adopting every new HTTP verb, and frankly there's a lot of value in making every endpoint accessible over GET and POST. Those who insist on strict REST are missing why it succeeded.
Re: Who Cares about GET vs. POST? NoREST
#43The criticism they start with is weird. They take this API call: OrderDTO Customer::GetOrder(int customerID, int orderID) And this HTTP call: GET /customer/33245/order/8769 And ask: > If we put the function name between the parameters themselves, then it leads to the question, what part of this URL is the endpoint? But the thing that is between the parameters is "order" not the function name "GetOrder". If you look a…
OTOH, "removing information from the URL for aesthetic reasons" may not be the best reason to move a safe operation from GET, which is defined as safe, to POST, which is neither safe nor idempotent, particularly if you are using middleware that is aware of HTTP semantics -- you've just thrown away valuable information. So a part of the point of and value of GET is to communicate idempotency? We can know certain parts…
The proxy will rely on distinction between GET and POST to know whether to cache.
More importantly, your enterprise Load Balancer with timeout and failover configured will feel free to repeat a GET request internally to a different server when the first server takes too long to respond. For a POST, it will instead throw an error to a user and perhaps trigger internal alert.
And if you think that's not a big deal, wait until your bank does a double international money transfer because their trigger call was implemented accidentally as a GET request and the network latency was bad. And hope, just hope, that they are not running 10 different servers behind the firewall and therefore falling over 10-1 times.... (true horror story from my tech support days).
Re: Who Cares about GET vs. POST? NoREST
#44I am increasingly getting irritated with REST for our app. It takes too much thought to figure out the "correct RESTful approach" when building out an API endpoint. And then again, there are no right answers. And all the JSON serialization/de-serialization logic, for every single endpoint. Too. Much. Work.
I'm wondering why Thrift/Proto-buffers aren't popular? Even for browser-based JS clients. What're the pitfalls?
Re: Who Cares about GET vs. POST? NoREST
#45The criticism they start with is weird. They take this API call: OrderDTO Customer::GetOrder(int customerID, int orderID) And this HTTP call: GET /customer/33245/order/8769 And ask: > If we put the function name between the parameters themselves, then it leads to the question, what part of this URL is the endpoint? But the thing that is between the parameters is "order" not the function name "GetOrder". If you look a…
> Whether REST is a style or a standard is irrelevant Yes it is relevant.People right on HN spend their time arguing over what is restful and what isn't ,because vague "semantics". with RPC,no argument.And to be frank, if you're not using HATEOAS , there is very little difference between a api with beautiful urls and a few headers and rpc. The original spec is brilliant yet way to vague to be useful. RPC isn't HTTP,w…
> People right on HN spend their time arguing over what is restful and what isn't ,because vague "semantics".
The defined semantics of HTTP/1.1 methods (REST is a style, but HTTP/1.1 is a standard) are not vague.
> And to be frank, if you're not using HATEOAS , there is very little difference between a api with beautiful urls and a few headers and rpc.
If you aren't using HATEOAS, you aren't using REST. That doesn't necessarily mean that it is indistinguishable from RPC.
> The original spec is brilliant yet way to vague to be useful.
What original spec are you talking about?
> RPC isn't HTTP,
Neither is REST, though HTTP is itself an example of REST and a protocol which is fairly convenient for use in REST services.
> which is totally handy in the context of micro-services as one can implement RPC over any protocol. that's not the case for Rest...
> On the contrary, it is rather central to the point of the REST architectural style that you can implement it over any protocol (or, given hypertext formats which support identification of different protocols, over any combination of protocols simultaneously.)
From the creator of REST [0]:
A REST API should not be dependent on any single communication protocol, though its successful mapping to a given protocol may be dependent on the availability of metadata, choice of methods, etc. In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification. [Failure here implies that identification is not separated from interaction.]
[0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
Re: Who Cares about GET vs. POST? NoREST
#46Except that RPC-structured APIs are complete garbage to consume for external developers because, surprise, they don't know or care what your internal function names are. And if you aren't thinking about the experience of real or theoretical third-party developers when building your API, why even have one at all? If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your s…
Why, are external developers able to consume restful APIs without the need for any documentation on the system they're talking to? Aren't the various REST entities (and all the possible links between them, if you're doing HATEOAS) already part of a protocol the developers of external consumers need to know beforehand?
He didn't say external developers wouldn't need any documentation to consume a REST API. The implication made was that developers are more accustomed to REST, hence REST is easier to consume. Speaking for myself, I've found this to be true.
Re: Who Cares about GET vs. POST? NoREST
#47It would have been nice if he proposed something innovative moving forward, but this is a step back to RPC-structured APIs. After reading this though, I had to check to make sure it wasn't April 1st.
I think the whole point the article is trying to make is that REST isn't really a step forward from RPC. It just adds an overly restrictive taxonomy (i.e. in a complex practical application, you're probably going to run into a problem that doesn't fit the REST model well), and doesn't actually solve any real problems.
Re: Who Cares about GET vs. POST? NoREST
#48REST is good, better than RPC, SOAP... finally people can understand and use APIs easily and happily. The URL /customer/33245/order/8769 is perfect, looks like a directory path and reflect the relationship between the entities. Arguing about the best url, status code and best verb is the irrelevant part in REST. Why can't people just do whatever it works for the users while respecting the standards when they can ?!
I think you've inadvertently put your figure on the part that really matters. REST is worse than SOAP or something like Thrift for discoverability, worse for ease of use, worse for practically every criterion you could think about. The one thing it does right is being easy to explore with a web browser. So optimize for that. Make it easy for a developer to look at your API with a web browser. This means simple URLs.…
> REST is worse than SOAP or something like Thrift for discoverability
How?
> worse for ease of use
How?
> worse for practically every criterion you could think about.
I can think of lots of criteria, but very few on which I can see a compelling argument for REST being inferior to SOAP except "degree of support from libraries written to support SOAP".
Re: Who Cares about GET vs. POST? NoREST
#49> Why not simplify by removing parameters from the URL altogether? Caching. Put a caching proxy in front of your api endpoint and enjoy. This is the same reason you'll want to do: /api/customer/1234/order/abcd instead of: /api?customer=1234&order=abcd Because even if your cache includes query strings (which it may, and you can configure it to), you lose order. Now you also have to configure your cache to ignore order…
I feel like the author is advocating for an easy API over a _simple_ API. Yes, the author's ideas make programming easy. There's less cruft and it's faster to develop. But, he's loosing simplicity. REST is a simple API because you don't need things like ordering, etc... That makes it compossible with other simple technologies (like the caching proxy you mentioned).
Re: Who Cares about GET vs. POST? NoREST
#50If you are mapping your RPC-style API into a REST interface, you are doing it wrong. REST as an architectural style wants you to think as your API as a collection of resource representations that can be manipulated through simple verbs (as the one present in HTTP). It forces you to think about idem-potency, caching, namespacing, immutability and robustness. If your API doesn't have abstractions for long running proce…
And object orientation wants you to think about your API as a graph of objects, but going too far down this rabbit hole is how you end up with a mess of AbstractSingletonProxyFactoryBeans[1]. Yes, it's possible to adapt any system into a collection of resources, but the transformations necessary to do so can end up creating more complexity than is gained through only having resources and verbs. The supposed simplicity of REST can be like the simplicity of the Brainfuck language. There's only 8 commands! Easy!
And the idea that using HTTP somehow renders questions of performance irrelevant is bizarre. If Hacker News sent 10MB of uncachable CSS, spread over 100 HTTP requests, with every page load, would that be OK because performance isn't the most important goal of the web? People use HTTP because it's a ubiquitous protocol supported by virtually every device and language. Performance isn't the most important goal, but it's still an important one.
[1] http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingd...