When creating web service APIs, one of the first things you need to decide is what interface method should be used.  Two very common methods are REST over HTTP and SOAP over HTTP.  HTTPS could also be used for either for highest security.  (There are other methods such as JSON or XML-RPC, but I contend that they aren’t as widely supported as REST or SOAP.)

So which one to pick?  After using both methods, I tend to lean towards REST.  I like the simplicity of REST, both from the point of view of defining the API, but also because it can be easier to debug.  REST uses the HTTP verbs of GET, PUT, POST, and DELETE as the basis for implementing an API.  For example, to retrieve a file from a server, you would perform an HTTP GET after specifying the filename and path in the URL.  To me, this is easy to understand and very versatile.  It’s also pretty easy to debug by just using an “HTTP sniffer” like Wireshark or Charles to watch the traffic going back and forth.

SOAP, on the other hand, is more about providing strong typing for variables and for support of more elaborate structures.  By using a WSDL, it can be very easy to provide accurate documentation of the APIs to a programmer implementing a client.  And if both the client and server are implemented in a .NET programming language, it can be very easy to implement sophisticated APIs.  On the other hand, if you want your API to be widely used by lots of clients with disparate programming languages, many don’t provide nice support for SOAP and WSDLs.  And SOAP can be tricky to use and to debug because it requires more elaborate interactions between the caller and the server.  You could use an HTTP sniffer for debugging, but it’s harder to tell what’s going on.

So overall, I prefer REST.  It just seems cleaner to me.

This entry was posted on Monday, May 31st, 2010 at 2:55 pm and is filed under Software Development . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.