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