Why you use GET vs POST are conventions. There are no way to enforce any rules in web services and conventions help to make the things you are looking at recogn

Why you use GET vs POST are conventions. There are no way to enforce any rules in web services and conventions help to make the things you are looking at recognizable. And conventions do change over time. I think we need more HTTP verbs like START and STOP and I wish POST was NEW. Merge vs. update-all for PUT is still not well established and now we have PATCH. Such terrible names. I would love something like REPLACE and MERGE or something more descriptive. I also think that your customer order example could have been done better. Something like Your example: OrderDTO Customer::GetOrder(int customerID, int orderID) But that's the wrong side of the equation, that's the definition of the function. If you call the function it would look like this: GetOrder(myCustomerID, myOrderID) And an equivalent REST call would look like this with a little clean up. GET /orders/?id={id}&customer-id={customer-id} Doesn't look that much different to me. Sure you could have done GET /orders/{id}/?customer-id={customer-id}, but there is no reason why the above is wrong from a RESTful perspective. Why would you marshall a whole JSON payload to do a simple GET? You are not creating a tuple to pass the two parameters in your full-language function example, what's the reason it is required for the RESTful call? As I mentioned above HTTP needs a couple more verbs and aliases for the existing verbs. You think of situations like: START /timers STOP /trains A lot of the time we jam POST and PUT in this situation and they are poor substitutes for a larger verb vocabulary. I have built a few automation projects and any actions you do can usually fit into NEW GET UPDATE (merge) DELETE START STOP OPEN CLOSE still limited, but pretty good at covering almost all the verbs needed. You supply the nouns. NEW /vms START /vms OPEN /remote-desktop/1234 CLOSE /files/folder/path/to/file Especially with persistent connections in HTTP2 and web sockets and things of the kind OPEN and CLOSE will likely be need to establish these kinds of connections. You could probably get away with using START and STOP though, such as: START /remote-desktop/?computer=1234 As for HTTP error codes. They need an overhaul. 404 and 403 do the job fine, but giving the user an idea of whether their JSON was malformed (Syntax) vs. the data in the payload was invalid is difficult to distinguish with just 400. But the return payload should describe the error in detail. Not many conventions there to help. As for HATEOS, I used to think it was great, but I am meh on it now. It needs refinement.