Skip to main content

Trying to make sense of REST (over HTTP)

People who come from WCF/ Web Services background and  transition to RESTish type communication infrastructure make mistakes that follow a common pattern. I have seen it with people who are new to REST and with people who have spent some time working with RESTful services. (Throughout the post where every I mention REST I mean REST over HTTP)  The common misconceptions  are
  • Not understanding the difference between HTTP POST and GET, in fact having too little or no clue about HTTP Verbs. For most devs interaction with server involves calling a client proxy method, handling the request on server, sending a response back from server, handling the response on client. This abstraction means no one knows what happens at infrastructure level. When programming for HTTP one cannot ignore the abstraction, else we cannot take full advantage of the medium.

  • The manifestation of the above affect is, either every call becomes a POST or every call becomes a GET.
    • When every call becomes GET. All CRUD are done through url. I have seen people trying to do crazy stuff with urls just to pass data from client to server.
    • When every call becomes POST (easy to do as compared to GET) , we fail to leverage the advantages of GET.

  • Assuming making HTTP call via GET\POST makes a service RESTful. This is a very common misconception and I too am culprit of thinking the same. But as I read more about REST and looked at examples I realize how far was I from a real RESTful implementation. I highly recommend REST In Practice book which is a great resource if one is serious about understanding REST.

  • Thinking the performance gains comes due to absence of SOAP envelop. The real performance gains come when data gets cached.  This caching can occur at different locations starting from the servers network (reverse proxies), intermediaries, client network  (proxies) and client browser.

  • Creating RESTful service and marking most of GET's as non cacheable. The common cause of this is not understanding the cache expiration in HTTP and therefore not taking advantage of it.  Moreover during debugging cycles cached data is a pain to work with when one wants to test his\her fix.

These are some of the patterns that are at top of my head. What else can be added?


Popular posts from this blog

Caching Images downloaded from web on Windows Phone Isolated storage

I was helping on a Windows Phone application where the requirement was to cache the images the phone downloads on the isolated storage for offline viewing.
I wanted a solution which was simple and as transparent as possible. While researching I found  someone wrote a Silverlight converter for loading images from isolated storage. Taking that as a base I created a converted which can
Load image from web (http + https), and persist it to isolated storage.In case of network connectivity issues can load the same image from isolated storage. It does that by mapping the http url to a isolated storage location.In case the network is down and the image is neither there in cache, loads a default image, passed as parameter to converter.Here is the gist for the implementation.

To use the converter
Import the name space.Declare the converter as resource.Set the Image Source Property to use this converter like this 

AngularJS Model - ViewModel

Recently Robin Ward did a comparison between AngularJS and Ember (both the post and the comments are interesting read). One of the complaint that Robin had that AngularJS does not provide any specialized model class. As described in the blog

There is no standard Model base class, nor is there a component or interface in AngularJS that defines what a model is supposed to be.
What that means is that anything defined on $scope can acts as model, as this sample on the blog describes

For some (like me) this is the flexibility where as for others who want a more structural approach this is a nuisance.AngularJS does not even provide any definite guidelines around how the model should be actually designed to be effective with AngularJS

This leads to what we call as $scope pollution. We define multitude of properties on the $scope object and managing it becomes difficult.  Looking at the code one cannot tell what is the actual model and what properties are just to support UI logic.

Model Desig…