Java Reference
In-Depth Information
The addressability and operations are well defined and finite, and the hard stuff is delegated
to the data model (in the case of SQL) or the message body (in the case of JMS).
Why Is the Uniform Interface Important?
Constraining the interface for your web services has many more advantages than disadvant-
ages. Let's look at a few:
Familiarity
If you have a URI that points to a service, you know exactly which methods are available
on that resource. You don't need an IDL-like file describing which methods are available.
You don't need stubs. All you need is an HTTP client library. If you have a document
that is composed of links to data provided by many different services, you already know
which method to call to pull in data from those links.
Interoperability
HTTP is a very ubiquitous protocol. Most programming languages have an HTTP client
library available to them. So, if your web service is exposed over HTTP, there is a very
high probability that people who want to use your service will be able to do so without
any additional requirements beyond being able to exchange the data formats the service
is expecting. With CORBA or SOAP, you have to install vendor-specific client libraries
as well as loads and loads of IDL- or WSDL-generated stub code. How many of you
have had a problem getting CORBA or WS-* vendors to interoperate? It has traditionally
been very problematic. The WS-* set of specifications has also been a moving target over
the years. So with WS-* and CORBA, you not only have to worry about vendor interop-
erability, but you also have to make sure that your client and server are using the same
specification version of the protocol. With REST over HTTP, you don't have to worry
about either of these things and can just focus on understanding the data format of the
service. I like to think that you are focusing on what is really important:
application in-
teroperability
, rather than
vendor interoperability
.
Scalability
Because REST constrains you to a well-defined set of methods, you have predictable be-
havior that can have incredible performance benefits. GET is the strongest example.
When surfing the Internet, have you noticed that the second time you browse to a specific
page it comes up faster? This is because your browser caches already visited pages and
images. HTTP has a fairly rich and configurable protocol for defining caching semantics.
Because GET is a read method that is both idempotent and safe, browsers and HTTP
proxies can cache responses to servers, and this can save a huge amount of network
traffic and hits to your website. Add HTTP caching semantics to your web services, and
