11–20 of 106 posts
How the url is formatted is irrelevant for REST.
If you ignore HTTP verbs and status codes you're just making it harder for other developers to grok your system. It's less about adherence to some strict standard and more about helpful signaling. A GET fetches data, POST creates new records, PUT is idempotent, DELETE deletes. 4xx status codes indicate a request error, 5xx indicate a server error. That's all useful information for someone trying to integrate with your API, but you think that instead everyone should memorize your in-house conventions. Good luck getting buy-in on that.
The only partial agreement I'd give to this is that I no longer think it's wise to nest multiple levels of resource IDs (e.g. /customer/123/order/456). This is, again, out of respect for external developers. Instead, I would have /customers/123 and /orders/456 (assuming that IDs can't be duplicated between customers). A flatter URL structure (which is, note, still REST-friendly) can be an easier-to-consume experience for other devs.
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…
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?
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…
But, yes, a key thing communicated by HTTP method used in a call is whether the call can be relied on to be safe, idempotent, or neither.
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…
Except 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…