Beautiful Architecture Chapter 5: Resource-Oriented Architectures

This was the first reading that gave me at least as many questions to research as useful nuggets of information. My experience with SOAP web services is limited to what are basically RPCs via XML within a single application (don't ask). Given that, I haven't felt much of the pain that the author associated with SOAP, so I'm interested to do some more research and discover what the downsides are when you try to utilize SOAP in more complex ways.

One thing that confused me was the way that the author repeatedly said that REST has the benefit of allowing you to upgrade the back-end systems without breaking the clients, implying that this is not possible with SOAP. My limited knowledge of SOAP leads me to believe that you can change any implementation details that you'd like without impacting the clients because it is not too difficult to keep your XML responses looking the same. I'm interested to see the scenarios where this is not the case.

I haven't used REST before but have done quite a bit of reading on it since it's all the rage. This chapter finally tied together my loose and disconnected understanding of the pros and cons, and I feel that I walked away with a pretty solid knowledge of how to compare REST to similar forms of communications. For some reason, this was the first time that it really stuck that http://server/getemployees&type=salaried is just an RPC via URL, and you may as well use SOAP. REST uses the same location for all of its CRUD operations; the type of operation determines which action is taken.

I know from firsthand experience the benefits that can be gained from having the same data available at the same location in different formats depending on the request context. Too many times I've run into problems where what is supposed to be identical data is going to the screen, a graph, and an Excel document, but there always ends up being just a little more or a little less processing done in one format. The fact that there are different endpoints makes it easy to modify one while omitting the others. When the numbers don't match up, it can take way too long to track down the bugs.

I think the fact that REST has only four verbs is just perfect in most scenarios. As the author mentions, most scenarios in industry involve information management, and post, get, put, and delete cover all of your CRUD operations. The author does make the point that SOAP does have it's place; it's better at invoking arbitrary behavior, but I find that REST would suit my needs 99% of the time. The few times that I need something with a semantic meaning that doesn't quite fit into the REST model, I'll handle them separately. There's no need to hinder the majority of cases for the exceptions, though. The four simple verbs also don't preclude you from having as much or as little processing between the request and the data store. It's not like each GET request has to pull back a row straight from your database to be processed by the client.

As an enterprise application developer, data management is my world. You could probably reduce almost every task that I work on to being creating data data or slicing and dicing it hundreds of different ways. Every technology has contexts in which they shine and others where they do not. The job of the architect is often to find the right tool for the job at hand. REST would be such a tool in my everyday life.

I was really interested by the author's points that it is better to pass around paths to the data to different applications rather than the data itself. I never really thought of how much easier an audit would be when you don't have to trace the path of the data through a maze of connections. I also liked how he pointed out that most people overlook the fact that the context of a REST operation provides all the information necessary to fully secure it. The manipulation of the data and the context in which it is done are orthogonal.

I loved the idea of using 303 responses from a server endpoint to redirect clients to the new location. The clients won't be broken when things get moved around, but you don't have to manage any kind of complex internal mapping of resources and endpoints.