REST Anti-Patterns
When people start trying out REST, they usually start looking around for examples - and not only find a lot of examples that claim to be “RESTful”, or are labeled as a “REST API”, but also dig up a lot of discussions about why a specific service that claims to do REST actually fails to do so.
Why does this happen? HTTP is nothing new, but it has been applied in a wide variety of ways. Some of them were in line with the ideas the Web’s designers had in mind, but many were not. Applying REST principles to your HTTP applications, whether you build them for human consumption, for use by another program, or both, means that you do the exact opposite: You try to use the Web “correctly”, or if you object to the idea that one is “right” and one is “wrong”: in a RESTful way. For many, this is indeed a very new approach. […] As with any new approach, it helps to be aware of some common patterns. In the first two articles of this series, I’ve tried to outline some basic ones - such as the concept of collection resources, the mapping of calculation results to resources in their own right, or the use of syndication to model events. A future article will expand on these and other patterns. For this one, though, I want to focus on anti-patterns - typical examples of attempted RESTful HTTP usage that create problems and show that someone has attempted, but failed, to adopt REST ideas.
Let’s start with a quick list of anti-patterns I’ve managed to come up with:
- Tunneling everything through GET
- Tunneling everything through POST
- Ignoring caching
- Ignoring response codes
- Misusing cookies
- Forgetting hypermedia
- Ignoring MIME types
- Breaking self-descriptiveness
Let’s go through each of them in detail.
More on InfoQ.
Hello Stefan,
Thanks for another great article — I am looking forward to the future ones that will go more in depth.
I was wondering about two of your points:
Point 5. “misusing cookies” - As you mention, the usual way of performing authentication in web applications is to assign a session id to each fresh request, keep this as a cookie and then store session information at the server which says, e.g., the session id is authenticated and corresponds to user X. You seem to argue that the restful approach would be to avoid this and use e.g. HTTP Basic or Digest authentication, is this correct? At first thought this seems impractical… What would you say? In practice what would you do for your ‘common-case ajax web-app’?
Point 6. Hypermedia. I like this principle, but I’m wondering about the consequences of taking this approach to the extreme. Often you want composite or ‘aggregate’ representation of resources. For example, a user might have a userprofile and account information, etc. If you want a representation of this user, say in a web-app, you often want a page composing username (a property of the user resource) with adress (say userprofile) and account number (account resource information). You can fetch the user resource which links to it’s user profile which may in turn link to the account. In this approach, being REST compliant entails many more HTTP request than a single aggregate i.e., non-hypermedia based approach.
In general suppose you want a summary view of a collection resource. You can represent your collection as a list of links to the individual resources, or you can aggregate the collection to one large response. If you do the former, you potentially have n requests where a single would be enough. Of course you may argue the other way around, but the discussion is still valid.
What is your opinion on this? It it better to create a new aggregate resource specifically for this purpose?
Thanks, — Karl
Excuse me for closing comments here – let’s have the discussion in one place (i.e. over on InfoQ).