Take the 2-minute tour ×

Given that RESTful web services are all based around the sacred idea that "everything is represented as resources and can be accessed by an address (URI)", this may make sense for CRUD applications (all examples are about listing/creating/updating/deleting entities). However, how about other business logic like, for example, creating a simple calculator RESTful service that has nothing to do with CRUD operations? What can be a good design for such a REST service?

Secondly, what is the real advantage of using REST over SOAP if the logic of SOAP already makes complete sense?

share|improve this question
So what exactly is your question? –  paulsm4 Nov 26 '11 at 0:11
add comment

2 Answers

up vote 4 down vote accepted

A calculator service would be simple to model in a RESTful manner. The "R" in "CRUD" stands for "read", and there's no reason that "read" can't also mean "compute". So a simple Reverse Polish calculator service could be accessed via GET:

GET https://calc.com/rpnCalc?3&4&%2B

The URI scheme above simply adds three parameters to the GET request:

+ (URL-encoded as %2B)

That's an idempotent, safe and cacheable request. If this was an insanely complicated math query that took many minutes to compute I could route these queries to an out-of-the-box HTTP proxy and use it to instantly return any pre-computed values should the same URI be queried repeatedly.

Depending on the kinds of calculations you need to do, you could also POST a very complex query to a Calculator resource (passing in the query as the request body) and the server might return the URI to a "result" resource, which you can then GET to retrieve the results, and even paginate through them.


I can access the above calculator service using a command-line tool like curl without building a complex piece of SOAP. I can code calls to it in seconds without having to use any third-party XML library or SOAP toolkit. I can use commodity tools like HTTP proxies to cache results and improve performance. I don't have to worry about SOAP interoperability or check for WS-I compatibility. If I use hyperlinks correctly then I can evolve and improve my service without affecting existing clients or having them to even recompile. There's no WSDL to version and no brittle contract which I have to maintain for years. The clients already know what GET/PUT/POST/DELETE do and I don't have to redefine or re-document their semantics. API clients that decide they'd prefer JSON instead of XML can get it using HTTP's inbuilt content-negotiation feature. I can do absolutely zero of these things with SOAP and Web Services.

Hey, if SOAP fits your needs, have at it. There are many benefits to using REST but they might not be appropriate to your situation. At the very least, learn about what REST can give you with a decent book like this one and then make your mind up after getting the full story.

share|improve this answer
Thanks Brian! So if methods can also be modelled as (sub-)resources, can I also write "GET calc.com/arithmeticCalc/add?a=3&b=4"; ? –  karimyafi Nov 26 '11 at 11:19
Yes, but I'd avoid adding verbs to your URI structure. You already have verbs within HTTP, so you should just use nouns to describe your resources within your URIs. That way your API clients won't be confused about how to use each resource. Imagine you do an HTTP POST to an /add resource - how would I know if it would do an actual addition or create a sub-resource? To avoid the confusion in your example, I'd change it slightly to calc.com/arithmeticCalc/adder?a=3&b=4. –  Brian Kelly Nov 26 '11 at 17:32
add comment

This is a good example of the tension between nouns and verbs in REST. The suggestion to use "add" or "adder" as the resource is tremendously naive. It implies that each operation be done as a GET to an "adder" or "subtractor". Of course one can have the resource be "calculate" but then we've using a verb. We can change it to "calculator" or "answer", which are nouns but we really haven't done anything useful.

share|improve this answer
add comment

Your Answer


