REST's approach to capturing semantics is different from the Remote Procedure Call (RPC) model common in SOAP-based services today. RPC places almost all semantics in the method of an operation. It can have preconditions and postconditions, service level agreements, and so forth attached to it. REST splits the semantics of each interaction into the three components. Most of REST theory can be boiled down to using URLs for identification, using the right transport protocol, and transporting the right data formats over it.
REST's interaction semantics can still be seen in its methods. We know from seeing a HTTP PUT request that information is being transferred from client to server. We can infer information such as cacheability from a completed HTTP GET operation. However, this is clearly not the whole interaction.
The next level of semantics is held in the document being transferred. Perhaps it is a purchase order, which can be interpreted in the same way regardless of the interaction context. Was the purchase order PUT to my service to indicate that the client wants to make a purchase, or did I GET the purchase order from a storage area? Either way, I can process the purchase order and make use of it in my software.
This leads to the final place where semantics are captured in REST's uniform interface: The context of the interaction, in particular the URL used. I could PUT (text/plain, "1") to my mortgage calculator program, and it might adjust my repayments based on a one year honeymoon rate. I could issue the same PUT (text/plain "1") to the defence condition URL at NORAD and trigger world war three.
This variability in possible impact is a good thing. It is a sign that by choosing standard interactions and content types we can make the protocol get out of the way of communication. Humans can make the decisions about which URL a client will access with its operations. Humans can make the decision about how to implement both the client and server in the interaction. Some shared understanding of the interaction must exist between the implementors of client and server in order for the communication to make sense, but the technology does not get in the way.
When you build your greenhouse abatement scheduling application, it won't just be able to turn the lights off at night. It will be able to turn off the air conditioning as well. When you build your stock market trending application it will be able to obtain information from multiple markets, and also handle commodity prices. Chances are, you'll be able to overlay seasonal weather forecast reports that use the same content types as well.
Moving the semantics out of the method might feel to some like jumping out of a plane without a parachute, but it is more like using a bungee rope. The loose coupling of REST means that applications work together without you having to plan for it quite as much, and that the overall architecture is able to evolve as changes are required.
SOA advocates: You like to tell us that you don't to RPC anymore, but what is the difference between RPC and your approach? It is interesting that the best google hit I found for this sort of information is this 2003 piece, by Hao He. The strange thing is, it sounds like REST's approach to me.
Here is another xml.com article, this time by Rich Salz. In his view the difference is that SOA separates "contract" from "validation". Is this the same point of view, or a completely different one? It can be hard to tell.
Another piece is by Yaron Goland. Again, I think it is making the same sort of point. This time that SOAP has failed to result in true SOA. Perhaps the only true SOA is one built on REST principles?
Whichever way you cut it, I think the important thing from the REST point of view is not to put too much context into the actual communications protocol. That should be agreed out of band, and be implicitly communicated through the chosen URL. Actual message structures consisting of an identifier, information about the requested interaction, and a payload should be as consistent as possible across as wide a range of problem domains as possible.
Benjamin