Web services were introduced as a means for different computer systems to interact by network even though they may be implemented in different technologies and with different implied domain models. SOAP is probably the best well-known protocol for doing this, though there have been others. These days there is a whole bunch of specifications over and above those for SOAP; together these are typically called WS-*.

Whatever; what characterizes the WS-* implementations is that they expose only a single endpoint to be invoked; in effect just another way of doing a remote procedure call. Put another way, WS-* -style web services provide an for a verb - "do this for me". In fact, this RPC endpoint usually accepts many different message types, and uses some sort of dispatcher to route the message so it can be processed correctly.

REST (standing for REpresentational State Transfer) in contrast is a style of designing web services that is modelled on the human web sites. Rather than expose a single endpoint, it exposes multiple endpoints. And these endpoints don't represent verbs, they represent things (or nouns). But REST goes further than this, because it also restricts what we can do with those resources to the standard HTTP verbs: GET (read), PUT (update), DELETE (er, delete) and POST (invoke, or change in some way). The first three of these are idempotent (can be invoked multiple times with no side effects). This is an important characteristic for building scalable systems, and is not one that the RPC approach towards web services supports at all well.

What happens if we perform an HTTP GET on a resource? Well, we get a representation of that resource. REST doesn't mandate what that representation is, but typical choices are JSON, XHTML or a custom XML dialect. However, what REST does emphasise is that these resources should be linked together, again analogous to the way that the human web works with hyperlinks.

So REST is much more closely associated with the web - and HTTP in particular - than WS-* -style web services ever were. But - so the thinking goes - the vast majority of web services are deployed over the web, so why disregard the web's semantics?

For much more on the design principles and philosophy behind REST, you might want to read Richardson & Ruby's RESTful Web Services.