Why RESTful Web Services Matter: Part 2

In Part 1, I mentioned that RESTful web services normally have a unifrom interface. Today, I will talk about the benefits a uniform interface offers in general.

There are a number of reasons why RESTful web services conform to a uniform interface. They are similar to the reasons JavaBean APIs only work with properties (often implemented as getters and setters). Given a uniform interface across different applications, clients can always expect the same operations to exist when given a resource name, thus one client can potentially be written to handle many different services.

With RESTful web services, the standard operations are CRUD, which are typically handled through the HTTP operations PUT, GET, POST, and DELETE.

For example, if a developer hears of a RESTful web service at www.contactzmanager.com that stores "contact" resources, the developer can assume that it is possible to perform an HTTP GET on http://www.contactzmanager.com/contact/ to list all contacts, and http://www.contactzmanager.com/contact/35 to retrieve a contact with ID 35.

Benefits of Uniformity in RESTful web services are:

• Non-existent learning curve


• Ease of consumption with minimal work


• Accessiblity to a wide range of clients

SOAP Web Services on the other hand require developers to make extra effort to learn application-specific APIs and adjust their code to handle them. This decreases the potential number of clients that will consume these services. For example, a banking service API may contain the operations withdraw, deposit, and checkBalance while an order service API may contain the operations listProducts, submitOrder, cancelOrder. Each application will require different consumption code.

Nonetheless, one thing that kept me skeptical for a long time about RESTful web services is the fact that SOAP Web Services can better reflect the domain model's terminology by allowing operation names such as: withdraw, deposit, authorize, etc...

Why am I finally over that obstacle? Martin Fowler mentions in his book Patterns of Enterprise Application Architecture that the majority of his enterprise integration projects involved no more than CRUD operations across the different applications. In other words, while Object-Oriented Design principles that encourage us to name operations according to domain terminology help immensely in managing complex domain concepts, the integration domain is usually simple enough that we can elect to leave that benefit behind in favor of ease of learning and support.

Stay tuned for more discussion about the benefits of the uniform interface.

Go to Part 3 here.