Why RESTful Web Services Matter: Part 1

Lately, I've been trying very hard to decipher the whole buzz around RESTful web services. After all, when I first heard about them, I had these first impressions:

• It is cool that RESTful web services are simpler than SOAP Web Services, but do we really care given SOAP's automatic generation technologies?


• Why CRUD??? This is heresy against Object-Oriented Design and Domain-Driven Design. After all, you normally want your operation names to match the language people use in the real world as closely as possible. It feels try-hard to twist the domain operation names into fitting the Create Read Update Delete scheme. For example, the stakeholders naturally think of authorizing payments, not posting a payment authorization. Of course, you can still do RESTful/RPC web services, which allow more operations on top of HTTP post, but according to O'Reilly's book RESTful Web Services, these are not truly RESTful.


• I like how RESTful web services usually have a lighter format for message transmission.

It took me a while to realize that there are two main differences between RESTful web services and SOAP Web Services:

• RESTful web services generally have a uniform interface by limiting operations to CRUD. SOAP Web Services have varied interfaces with potentially many different operations.


• Because of the previous reasons, RESTful web services do not seem to impose a standard on the message format. The HTTP protocol helps convey which operation you are performing regardless of the message data. SOAP on the other hand does impose a standard for the message format, which includes information about which operation is being performed.

Stay tuned as I discuss each one of these points separately in different blog posts.

Go to Part 2 here.