While I like the standardization afforded by REST, I frequently run into some artificial limitations that are imposed on the different request methods. For example, I find that I would frequently like to pass structure information in a GET that would be more useful to send in a body (as afforded by a POST).
One prime example relevant to this article would be a GET that was effectively a query by example. So a client could basically submit a skeleton of the data that it would like.
This would let a client "go deep" on some portions of the structure and shallow on other aspects. Imagine the following GET request for that calorie counting Android App in the post:
GET /orders/432544
{ "toppings":
[{ "calories": ""}]
}
This would give any client the ability to ask for exactly what it wanted with different depths to the structure if necessary. While you could serialize that into a URL, that seems like a kludge. I think in general, the HTTP methods made sense for their original design, but as we move on to building more flexible, integrated data system, a more powerful flexible API mechanism may be warranted.
GET is for retrieving a resource, which is like a fixed representation of data. In your example, you're trying to do a function call, an RPC, and badly mapping it to HTTP semantics.
That's what POST is for.
You could maybe do something like this:
GET /orders/432544 HTTP/1.1
Host: www.example.com
Accept: application/json;bsaunder=1.0;calories
And, of course, technically, you CAN pass a body with your GET. The spec does not disallow bodies on GETs. Roy Fielding, however, would disapprove:
> GET is for retrieving a resource, which is like a fixed representation of data. In your example, you're trying to do a function call, an RPC, and badly mapping it to HTTP semantics.
I don't really agree with that: he wants to retrieve a subset of a resource, that's a resource in itself. Using a more standard selection language, his query could be rewritten:
GET /orders/432544?path=%2Ftoppings%2Fcalories HTTP/1.1
My read is that without id's, having broken-out calories like the GGP's is a broken data model and/or API. The API should be returning a sum of the calories for a particular order, which supports GP's "RPC" argument. Either that, or returning ingredient ids with their calories counts.
> My read is that without id's, having broken-out calories like the GGP's is a broken data model and/or API.
IDs are not involved at any point, and are not even relevant to bsaunder's comment.
> Either that, or returning ingredient ids with their calories counts.
An API which returns identifiers is not a REST API, so this statement makes no sense.
Now more to the point, bsaunder is simply looking for a way to fetch a subset of a resource by providing some sort of filter. I truly do not see why that would not be restful, it's simply a search query, what do you think happens when you search something in Google? It returns a resource which is the subset of an other resource (their complete index, which they don't expose but that does not really matter), and as far as I can tell nobody's accused search engines of failing to be restful yet.
> This would give any client the ability to ask for exactly what it wanted with different depths to the structure if necessary. While you could serialize that into a URL, that seems like a kludge.
Not sure why: your structure looks like an ad-hoc (and hard to read) selection query language (e.g. XPath, CSS selectors, ...). I'm sure it sounds good when throwing the idea in the air "oh the response has the exact same shape as the body", but I'd expect it to not be very good in practice (much like Go's weird-ass date formats)
A better way is to PUT the template as a resource that you can GET with query paraneters later and which would fill that template. Like creating a prepared query.
One prime example relevant to this article would be a GET that was effectively a query by example. So a client could basically submit a skeleton of the data that it would like.
This would let a client "go deep" on some portions of the structure and shallow on other aspects. Imagine the following GET request for that calorie counting Android App in the post:
With a response that would be: This would give any client the ability to ask for exactly what it wanted with different depths to the structure if necessary. While you could serialize that into a URL, that seems like a kludge. I think in general, the HTTP methods made sense for their original design, but as we move on to building more flexible, integrated data system, a more powerful flexible API mechanism may be warranted.