wRESTling with REST

I'm still struggling with the decision to create a REST or traditional web service. Over the weekend I started reading RESTful Web Services and I'm now thinking that a RESTful approach is very doable. Here are my thoughts:
  • REST resources are inherently stateless and shareable. All the information needed to reconstruct the view of a resource exists in the URI. Although I listed this a a "pro" before reading the book, I'm more convinced of the benefits now.
  • I had a concern about long query criteria in the URI, but I'm thinking of adopting the Ruby-like approach of referring to ids. The RESTful authors prefer a more human readable URI (as it is self documenting), but many of my filter criteria cannot be accessed through unique strings.
  • I believe I was trying to do too much at the beginning (not keeping it simple). My object relationships are complex, with most objects linked to several related (non-subordinate) lists of objects. I wanted to have a single interface with options to include specific subsets of data as well as page through the results.

    As I thought more about this, I began to think that these subsets should actually be separate URI requests. Clients will probably make more requests to the service for data, but underneath, my Ruby controllers were making multiple requests to the database anyway. Here I'm hoping that the additional overhead of multiple GET requests will be balanced by the simplicity and usability of the interface (and no SOAP overhead).

As I become more familiar with the concepts of REST, I'm getting more comfortable thinking of my objects in terms of URIs and resources opposed to RPC calls and parameters. It's kind of similar to the shift in thought from procedural programming to object oriented design.

Comments

Popular posts from this blog

I Believe...

More stuff to get excited about

A few quick notes