REST – Updating a resource has multiple side effects

I have seen REST or ROA described as Distributed Objects Realized and believe me I get it. However, different operations on objects have different side-effects and from an implementation perspective I struggle with why REST is necessarily better in ALL situations.

Let me give an example. Imagine a resource X that can be updated (PUT’d) in various ways and traverse multiple states, the representation (or payload) sent to my implementation will need to contain information on what “update”I want to do. In essence, my intent is not solely conveyed in the fact that I am using PUT – the consumer of my service needs to know the appropriate payload before they can effectively use my service. (Could it be that my resource design is wrong?) Knowing how to “PUT” to some resource doesn’t help them that much. I think this is a fact that is severely understated!

This is why I think the design of the messages passed between consumer and service is also quite important.

Somewhat related to this point is the fact that “SOAP bashers” conflate SOAP with RPC. I would counter and say you can do SOAP without RPC, in fact I do it all the time using the WSE toolkit and SSDL. My consumers just send a message to an endpoint using their protocol of choice and that’s the end of the story. Most interactions (at this point) are complex operations (PUTs?) and so I personally don’t seem to gain much from a standard interface.

Is the SOAP payload overkill in some (ok many) instances, yes! But I would suggest that has little to do with RPC in itself. Have Microsoft, Sun, IBM, industry trainers etc. educated people incorrectly when it comes to SOAP-based web service design? Probably.

Having said all that, I believe RESTful solutions have their place in my toolkit. The nature of the client and the service that I need to provide ultimately drives how I build my service. Distilling requirements to the point where I know what tool to use is the hard part. 🙂

Now I could be missing the point completely here so if I am, feel free to comment and point out my error in thinking.


Processes or Data – Batching

Below is an entry that I delayed posting for approximately a week:

Tim Ewald has a great post that questions using REST-based architectures to handle process-driven operations. I think it’s a very valid question and one that I have to deal with daily. I also think people who promote ROA never really have great examples to cover these situations. Certain operations (in my opinion) do not map “cleanly” to ROA. It’s easy to map the creation of a single order using ROA, but what about when you want to “mass create” or “interface” hundreds of orders in a single interaction i.e. do things in batch – which a lot of integrators require? What is the resource at this point? If someone could map that to a RESTful interface for me, I’d be interested to see it.

I like he have definitely seen a variety of places where using ROA is definitely the way to go, but I think there are definitely situations where MOA (message-oriented architecture) just makes more sense. Distinguishing between the two is another challenge on its own but I think the interaction model and the nature of the “resource” plays a huge role in decision making.

Wait long enough and you’ll get answer. 🙂  Last night (thanks to Stefan Tilkov) I came across James Snell’s post on batching and truth be told, I find it intriguing.  I am not very familiar with the PATCH verb and will have to take a look at it.  This does come across as an elegant solution because existing state machines/resources/links that already exist for non-batch operations can be leveraged.  However, I do think the underlying implementation has to be smart from a links traversal angle as performance gains may be lost.

If you have any thoughts, let me know.  This is definitely something for me to ponder….