Sound advice - blog

I committed a few more bytes to the network, and have document what I think is the very core set of REST patterns. These cover from a patterns perspective many of the REST constraints. Only layering is called out explicitly as a pattern:

1. GET
2. PUT
3. Registry
4. Layering

Do have a read. Each of the patterns tries to cover the whole lifecycle of a series of requests and discuss the pros and cons of the choices made. I include information about what is important to supply in requests and responses, and how clients and servers should generally behave. Hopefully I'll be telling someone something they don't know. I'm trying to create something of a bridge between the practical and the theoretical in the REST space.

I haven't documented code on demand, the so-called "optional" constraint (which makes it sound like a pattern to me) of REST. I'll start working on others in the coming weeks and may cover it then. I welcome suggestions, contributions, critique, etc.

Benjamin

I have been starting to mentally collect a few common REST patterns of late. I have hacked up a little alternate feed where I plan to place some of these patterns.

The very phrase "pattern" might be a little strong for some of what I have in mind. Often we are talking about very simple structures of client and server, or more of an organisational construct to support a REST architecture. However, I will be attempting to document important trade-offs in any given pattern.

The first pattern I have attempted to document is GET. I do not cover all possible permuations of GET (I see some of these permutations a separate patterns). Instead, I have focused on the usage where a client wants to retrieve a defined small-ish set of data from its server.

Once all of the possible failure cases and the possibility of differently-aged software components in the architecture are considered, GET is actually fairly subtle set of optimisations. I have attempted to show the fundamental communication that is going on between client and server, then map it onto specific HTTP protocol elements.

I have been trying to follow the style of the Gang of Four's Design Patterns. However, I would generally expect that most of the patterns I will describe will be implemented in protocol libraries rather than requiring actual application-level code to participate in significant ways. Comments are welcome.

Benjamin