I thus want to know how many responses I may expect from a RESTful uri GET request. Right now, I'm not aware of a means to achieve that. Is it possible to accomplish? I'm not sure whether REST can take a count of its results since it merely outputs properties, however it can skip results and take a subset of results.
Anyone have any recommendations?
Oh, I have a LINQ to SQL setup that fills a generic list that can be queried. That list is made public by the data service. When I try to obtain a count on the list, I always get the maximum number of rows the database can hold, which isn't what I'm after.
Although some individuals would disagree with this idea, I think the following is reasonable:
HEAD /your/api HTTP/1.1 HTTP/1.1 200 OK Date: Fri, 23 Oct 2009 00:58:17 GMT Content-Type: application/xml; charset=UTF-8 Content-Length: 89 X-Result-Count: 100000000
GET /your/api HTTP/1.1 HTTP/1.1 200 OK Date: Fri, 23 Oct 2009 00:58:17 GMT Content-Type: application/xml; charset=UTF-8 Content-Length: 89 X-Result-Count: 100000000 <?xml version="1.0" encoding="UTF-8"?> <results> 100000000 results go here. </results>
Note: Here, the count is retrieved via a HEAD request rather than by pulling the whole collection of data. Only the HTTP headers are sent by HEAD requests; the response content is not returned.
The most RESTful approach I can think of to say how many results you're going to receive back before sending it over the wire is by doing it like this. Simply coming up with the ideal header name for it is the key challenge.
is good, but if you can identify earlier works and utilize their header name, it would be much better (provided they didn't choose a name that was very stupid). However, I doubt you'll have much success, so you should probably stick with what you know.
Additionally, I believe that you may not have comprehended the true meaning of "REST." There is no reason why you can't provide a range as a representation. For instance:
GET /your/api?page=1&perpage=10 HTTP/1.1 HTTP/1.1 200 OK Date: Fri, 23 Oct 2009 00:58:17 GMT Content-Type: application/xml; charset=UTF-8 Content-Length: 101 X-Result-Count: 10 <?xml version="1.0" encoding="UTF-8"?> <results> First 10 results of 100000000 go here. </results>
To be RESTful, however, you must be able to inform the client of the representation indicated by
without using out-of-band data. To illustrate, suppose your
Whenever a website returns too many results, temporarily reroute traffic to
and include connections to
. Be aware that in this situation, a connection might be as simple as:
<?xml version="1.0" encoding="UTF-8"?> <results> <result> This is a result. </result> <result> This is also a result. </result> <link rel="next" href="/your/api?page=3&perpage=2" /> <link rel="prev" href="/your/api?page=1&perpage=2" /> </results>
The data you need to browse the API call results is currently in-band and really RESTful.
REST is really just plain old HTTP with proper caching and typically meaningful URIs added for good measure. Hypertext serves as the "engine of application state" as well (i.e. resources should link to other resources). It is an architectural style rather than a procedure. Anyone who claims otherwise had best go by Roy Fielding.
You may create the header as follows if you wish to compare the total count and page count:
or change as needed.
Why don't you provide query support for that kind of information in your resource? Imagine that
your list of objects is returned as follows:
<items count="5" modified="2009-10-22"> <item url="/items/first" name="First Item" /> <item url="/items/second" name="Second Item" /> ... </items>
Afterward, something like:
may provide a list that is empty:
<items count="5" modified="2009-10-22" type="info" />
or even a paper with general information like this:
<info> <items count="5" modified="2009-10-22" url="/items" /> </info>
You might also use an information resource similar to this:
which could come back:
<info> <items count="5" modified="2009-10-22" url="/items" /> <users count="8" modified="2009-10-05" url="/users" /> </info>