It 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.
Who Cares about GET vs. POST? NoREST
31–40 of 106 posts
Re: Who Cares about GET vs. POST? NoREST
#32Except 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…
> If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your system
That's not what the article suggests (ignoring?). I totally disagree with maintaining (http verb) semantics for operations that can (and usually do) change over time. Simple JSON posts for everything make APIs simpler. There's nothing about convention, just APIs which may have irrelevant conventions.
Re: Who Cares about GET vs. POST? NoREST
#33It 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.
Gaining experience in technology is absolutely exhausting. Everyday there are posts, "New Shiny X!" and then six months later "Introducing No-X". Then a year later "New Shiny Y! Like X but without sesame seeds on the buns!"
Re: Who Cares about GET vs. POST? NoREST
#34Pure REST is great for toy examples, where every domain entity fits neatly into a resource and every operation is a CRUD one that can be represented as an HTTP verb. So there is a million tutorials explaining how to build a REST API for a blog with BlogPost and Author resources, or an ordering system with Customer and Order resources.
However, when you move beyond these simple examples and start trying to build a REST API for a messy, complex system, you immediately run into trouble. How do you deal with non-CRUD operations? How do you deal with long running processes? Or entities in an indeterminate state? How do you aggregate multiple resources into individual request/responses for performance? How do you de-duplicate identical entities within an aggregated response? How do you return only particular fields? How do you handle paging and filtering? How do you handle transactions? How do you handle authentication and security restrictions?
All of these things can be solved, but by the time you've finished, your API will be far from easy to understand. It will need a load of accompanying documentation to make it usable, and will have a bunch of weird corners where you're initiating operations as a side effect of setting entity flags, or you've noun-ed verbs in order to turn an abstract operation into a resource. E.g. PUT /server-reboot-attempt.
Re: Who Cares about GET vs. POST? NoREST
#35Well REST allows for resources to be accessed as they are: resources. Using POST/GET query parameters implies that the server should do some actual processing on these to deliver the requested resource. With REST, you can have the resource be a static file on the server, no processing required.
I don't think you need REST to access a static file.
Static html files are the purest form of REST. What says HATEOS more that ?
Re: Who Cares about GET vs. POST? NoREST
#36The 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…
I don't understand why it isn't GET /getOrder?customerID=33245&orderID=8769 I mean, if you're going to go with this style, might as well go all-in on it, right?
[deleted]
Re: Who Cares about GET vs. POST? NoREST
#37If 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 processes or more complex business transactions, you don't have a RESTful API and need to adapt it.
Furthermore, if payload size and minimizing the number of requests is your most important goal, why are you using HTTP in the first place? It's not the right solution for you.
Re: Who Cares about GET vs. POST? NoREST
#38The 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…
I don't understand why it isn't GET /getOrder?customerID=33245&orderID=8769 I mean, if you're going to go with this style, might as well go all-in on it, right?
You surely meant:
GET /index.php?do=getOrder&customerID=33245&orderID=8769
Re: Who Cares about GET vs. POST? NoREST
#39How about this then?
GET /index.php?do=getOrder&customerID=33245&orderID=8769
Re: Who Cares about GET vs. POST? NoREST
#40The 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,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...