views:

96

answers:

2

In another question I asked for different implementations of a simple RESTful webservice. It was pointed out, however, that the API I defined was not particularly RESTful. My question: Is that a bad thing? More specifically: What are alternative ways to define such an API?
I'll add the answer from the problem definition in the other question. I'd love to see the strictly kosher RESTful version, as well as any other variations or improvements others can suggest.

The goal is to simply provide a service to sum a list of numbers. One webservice/API definition per answer, please!


(The point of course is not to literally provide such a silly webservice. This is meant to be a question about the elegant design of simple webservices, with this as a unifying example.)

+1  A: 

Here's the API to beat. A call of the form

http://server.com/sum?summands=LIST

should return

<sum>SUM</sum>

where LIST is a list of space-separated real numbers and SUM is the sum of them.

For example,

http://server.com/sum?summands=1+2+3

should return

<sum>6</sum>

Ideally, it would also provide an optional "output" parameter to specify the format of the results. For example,

http://server.com/sum?summands=2+2&amp;output=json

would return

{"sum" : 4}
dreeves
"where LIST is a list of space-separated real numbers" maybe a different seperator than space would be good, since spaces in URLs is rather frowned upon. (in your example I can see you yourself use a "+") other than that: just right =)
dionadar
Thanks! A '+' is actually a standard way to encode a space in a URL so '1+2+3' is a url-encoded rendering of '1 2 3'.
dreeves
+1  A: 

I will start with the caveat/excuse that REST's benefits start to show for larger and more complex APIs. The following solution will probably seem pretty cumbersome for such a trivial problem. Having said that,

First I would start by looking for an existing media type that can represent lists. I would not use query string parameters because I prefer to limit their use to being search filters. I'll use html as the media type because it is first one that comes to mind that supports lists.

<ul>
    <li>1</li>
    <li>2</li>
    <li>3</li>
</ul>

Second I would define a "data-handling" resource that will do the summing.

http://example.org/SummingMachine

I would use the POST method because RFC2616 says POST can be used for:

Providing a block of data, such as the result of submitting a form, to a data-handling process

So to do the sum I would do

POST http://example.org/SummingMachine

and send the html list in the body of the POST. The result could come back as something like:

<div class="result">6</div>

I would suggest that this solution is more RESTful than the original because

  • it uses standard media types for the representations
  • the resource that is defined is a noun instead of a verb
  • it uses POST to perform a "data-handling" process instead of using GET
Darrel Miller