Do you really know why you prefer REST over RPC?

Do you really know why you prefer REST over RPC?
apihandyman.io

A generic problem with REST APIs is they all handle collections, associating items with subcollections (including establishing and removing 1-to-many or many-to-many relationships between existing objects), query strings, authentication, and pagination very very differently. Not all APIs are discoverable either, many don't do structured error codes. Thus to talk to one, rather than just using client-library, more work has to be done, often repeated work in multiple languages. Lots of REST APIs aren't well discoverable and rely on special logic to form up URLs, and many have weird verb pollutions - modelling a long running job for instance, I've typically have done as posting a job descriptor to a job collection, because the standard verbs don't really apply.

All being said, I prefer a nice broweseable REST API, but despite the accursed "XML" in the name, XMLRPC was easy - there were bindings in multiple languages and it was easy to ask an API what methods were supported. Problems came in the undefined parts - like whether "None" could be passed, and so on.

I can design and build some very elegant REST APIs, but the clients DO have work to do, every time. A good example for me was trying to write to GitHub's API, and then being angry at the way pagination was overcomplicated and URLs were not discoverable. (It might have gotten better).

BTW, if you are doing Python and want a GREAT foundation in pagination, discoverability, and so on, I recommend Django REST framework. One catch is you may wish to extend some of the serializers to return URLs relative to other URLs.

I don't think RPC is evil so much - over HTTPS and backed by a good webserver, and done so that it's stateless (something a pre-forking webserver (esp with MaxRequestsPerChild in play in Apache) forces you into, not so much REST protocols all by itself), I think it's just not socially acceptable.

So statelessness good, having to write client-specific "flavors" of REST, well, it's just reality.

(In other news, I'm disappointed all my He-Man figures got sold in the 80s so I can't illustrate tech cartoons with them, well done)

REST GETs are fine for getters, and I generally like REST URLs because their prettier and don't have god-function smell like you get with SOAP.

But for commands, a POST with params to distinct URLs for each command works fine.

  def index
    if request.put?
      update_stuff
    end
    # get/put render same response content
  end