Tuesday, November 24, 2015

REST vs RPC

This is taken from: http://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/
And the author has done a simple and fair evaluation of the two.

Cached Copy

Conclusion:

ITEM	WHO WINS?
Beauty	Draw
Designability	Draw
API definition language	Draw
Predictability and semantic	REST
Hypermediability	Draw
Cachability	Draw
Usability	Draw

Do REST really wins?

REST wins thanks to the predictability and semantic item.
So, is the resource approach better than the operation one?

No.

RPC and REST are only different approaches with pros and cons and both are valueabledepending on the context. You can even mix these two approaches in a single API.

The context, that’s the key. There are no panacea solution, don’t follow fashion blindly, you always have to think within a context and must be pragmatic when choosing a solution.

At least, I know now why I like the resource approach: its predictability and the frame given by the full use of HTTP protocol. What about you?

One last word to leave you with food for thought: in this time of advent of functionnal programming, having operation request style could make sense…

Idempotent Methods - PUT, DELETE, and safe request methods

Idempotent Methods and understanding their behavior is critical to getting REST right and nothing explains it better than reading the spec about what it means.

4.2.2. Idempotent Methods

   A request method is considered "idempotent" if the intended effect on
   the server of multiple identical requests with that method is the
   same as the effect for a single such request.  Of the request methods
   defined by this specification, PUT, DELETE, and safe request methods
   are idempotent.

http://tools.ietf.org/html/rfc7231#section-4.2.2