The criticism they start with is weird. They take this API call:<p><pre><code> OrderDTO Customer::GetOrder(int customerID, int orderID)
</code></pre>
And this HTTP call:<p><pre><code> GET /customer/33245/order/8769
</code></pre>
And ask:<p>> If we put the function name between the parameters themselves, then it leads to the question, what part of this URL is the endpoint?<p>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:<p><pre><code> Customers[customer_id].Orders[order_id] # => Order
</code></pre>
> REST URLs look ‘cleaner’, but are they easier to understand?<p>Yes.<p>They go on to say:<p>> 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.<p>With this example:<p><pre><code> GET /customer/getOrder?customerID=33245&orderID=8769
</code></pre>
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?<p>> Why not simplify by removing parameters from the URL altogether? Put them in the query string, or post body as JSON.<p>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.<p>> 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?<p>Why <i>not</i> 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.<p>> 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.<p>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.<p>> REST is a style, not a standard.<p>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.