Who Cares about GET vs. POST? NoREST

#1

Post by swax » Tue, Mar 03, 2015, 4:49 PM UTC

Who Cares about GET vs. POST? NoREST
swaxblog.tumblr.com

Re: Who Cares about GET vs. POST? NoREST

#2

Post by xienze » Tue, Mar 03, 2015, 5:14 PM UTC

Congratulations, you've discovered RPC.

Re: Who Cares about GET vs. POST? NoREST

#3

Post by dragonwriter » Tue, Mar 03, 2015, 5:20 PM UTC

The 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 at an alternative form in which one might (more idiomatically, in some languages) see the API call, the relation to the HTTP call is more clear:

  Customers[customer_id].Orders[order_id]  # => Order

> REST URLs look ‘cleaner’, but are they easier to understand?

Yes.

They go on to say:

> A simpler API, similar to our original function call would have no mixing of parameters with the name, and clear definitions of the parameters being passed in.

With this example:

  GET /customer/getOrder?customerID=33245&orderID=8769

How is that simpler? Sure, depending on how you've implement the backend, it may be a more direct reflection of the backend code, but there is a difference between "leaky abstraction" and "simpler". Also, why is the fact that the action is "getting" something reflected twice?

> Why not simplify by removing parameters from the URL altogether? Put them in the query string, or post body as JSON.

Sure, RPC-over-POST is an alternative (older than REST) style of Web API, and if that's what floats your boat, do it. 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.

> Your API can encounter many application specific exceptions while processing a request, but why try to pigeon hole your error response into a limited number of error codes designed for retrieving hypertext?

Why not choose the best error code of those available in the protocol? In a traditional programming language, would you just throw the most generic possible exception? Because that's what the "just use 200 for success and 500 for failure" approach is equivalent to.

> Verb agnostic, HTTP verbs are really only needed to identify where parameters will go – for GET it’s in the query string, For POST, in the body.

If you are going to use HTTP, why fight against it by throwing out its defined semantics? Aside from reducing the value you get from existing HTTP-semantics-aware software, you are just forcing yourself to reinvent the wheel.

> REST is a style, not a standard.

Whether REST is a style or a standard is irrelevant when your post is advocating abandoning it completely in favor of RPC-over-HTTP with deliberate disregard for HTTP's defined semantics.

Re: Who Cares about GET vs. POST? NoREST

#4

Post by treve » Tue, Mar 03, 2015, 5:21 PM UTC

How the url is formatted is irrelevant for REST.

Re: Who Cares about GET vs. POST? NoREST

#5

Post by rcari » Tue, Mar 03, 2015, 5:22 PM UTC

Well 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.

Re: Who Cares about GET vs. POST? NoREST

#6

Post by creeble » Tue, Mar 03, 2015, 5:31 PM UTC

rcari wrote: post #5

Well 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.

Re: Who Cares about GET vs. POST? NoREST

#7

Post by namdnay » Tue, Mar 03, 2015, 5:32 PM UTC

dragonwriter wrote: post #3

The 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…

> advocating abandoning it completely in favor of RPC-over-HTTP

It surprises me that the author didn't go one step further and ask us to return to SOAP :)

Re: Who Cares about GET vs. POST? NoREST

#8

Post by nothrabannosir » Tue, Mar 03, 2015, 5:33 PM UTC

> 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 ordering on the query string, and that's a lot less obvious (and probably not even HTTP compliant?).

Re: Who Cares about GET vs. POST? NoREST

#9

Post by stcredzero » Tue, Mar 03, 2015, 5:34 PM UTC

dragonwriter wrote: post #3

The 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 of the API are idempotent because they are GET?

Re: Who Cares about GET vs. POST? NoREST

#10

Post by dragonwriter » Tue, Mar 03, 2015, 5:36 PM UTC

namdnay wrote: post #7

dragonwriter wrote: post #3

The 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…

> advocating abandoning it completely in favor of RPC-over-HTTP It surprises me that the author didn't go one step further and ask us to return to SOAP :)

I think that we're only a few years away from someone reinventing SOAP but with JSON playing the role of XML.