The point of REST is to reduce barrier to entry for using your API. There is a specification for web requests which works rather well, is relatively applicable

The point of REST is to reduce barrier to entry for using your API. There is a specification for web requests which works rather well, is relatively applicable for any resource oriented service, and has well defined semantic conventions/specifications for failures, operations on resources, and responses to operations. It's an incredibly well known & understood specification. Any things you wonder have almost certainly been asked a thousand times before, and a single Google search will invariably land you on Stack Overflow with a productive discussion about what the best approach is. Why not make use of this? You lose nothing by generally following the standard (since you can deviate from them whenever you need), but you gain so much - both from the perspective of building your API, and from the perspective of a potential person using your API. --- Also two things specifically came to mind to mention: > Who Cares about GET vs. POST? There are very practical implications from the use of GET/POST. Any GET request you support can be called from any website without any knowledge from the user. For example: <img style="display:none" src="https://example.com/user/setPassword?password=foobar" /> By using a POST, along with standard cross origin protections, it is much more difficult for a malicious website to have any impact on your user. (Although CSRF checking should be done anyway) "Well then, I'll just use POST for everything", you might say. There are a great number of downsides for that also: preventing caching, not allowing cross-origin communication without CORS, clients not being sure about idempotency, etc. --- > "If we put the function name between the parameters themselves" I found this interesting, because there is a language which does this - Objective C. These are fairly equivalent: GET /customer/getOrder?customerID=33245&orderID=8769 customerGetOrder(33245, 8769) And these are equivalent, but oriented the 'RESTful' way: GET /customer/33245/order/8769 [self getOrder:8769 forCustomer:33245]; Customer.find(33245).orders.find(8769); Personally I think the latter examples work much better in a resource oriented service. They show logical structure, relationship between objects, etc.