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.
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:
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:http://stackoverflow.com/questions/978061/http-get-with-requ...