Performance Zone is brought to you in partnership with:

Lorna Jane Mitchell is a PHP developer, blogger, trainer and evangelist from Leeds in the UK. She is active with phpwomen.org and her local user group PHP North West, and writes for a variety of outlets, including her own blog at lornajane.net. She is an active member of the PHP and open source communities and contributes to the joind.in event feedback project. When she's not at her computer, Lorna enjoys yarn craft, hobby electronics, and her home renovation project. Lorna is a DZone MVB and is not an employee of DZone and has posted 78 posts at DZone. You can read more from them at their website. View Full User Profile

Five Clues That Your API isn't RESTful

01.24.2013
| 3653 views |
  • submit to reddit

I get a lot of emails asking me to get involved with API projects, and that means I see a lot of both implemented and planned "RESTful" APIs. Now, I absolutely love REST and for a data-driven application, it would be my first choice. A service of some other description may work better for other scenarios or skill sets, and non-RESTful services can be very, very useful. If you tell me that your service is RESTful, then I expect it to be. If you're not sure, look out for these clues:

It has a single endpoint

I don't really care what else is going on in your API, any "RESTful" API which has a statement such as "all requests are made to http://example.com/rest" is ... not RESTful. REST is all about handling representations of resources, each is represented by its own URI and we operate directly on that. If it looks like "pretty URLs", then it's probably along the right lines.

All requests are POSTs

While it is completely valid to have POST requests in a RESTful service, if all requests to this API are to be made using POST, it's very unlikely to be RESTful. POST requests create new resources, so if that's all that is happening, then great. If you're able to retrieve, update or delete data, then this isn't a RESTful service.

Response metadata is in the body, not header

Any sign of data along the lines of status = success in the body of the response again means that this isn't RESTful. REST takes advantage of the HTTP envelope format and puts all the supporting metadata into the headers of the requests and responses. The body of the representation is literally just the representation of the resource.

There are verbs in the URL

This can be quite subtle but shows up especially with subresources. Look out for something like /item/42/activate ... REST deals with resources, an "activate" isn't a resource. If you're modelling a service, maybe something like /item/42/status could make a better alternative.

The URL includes method names

This is the easiest "tell" by miles. The most obvious non-RESTful aspect is when the URL has something like ?action=getRecentItems in the URL. Sometimes, this clue gets combined with another one, and the method name will even be in the body of the message - definitely not very RESTful!

Do We Care About RESTfulness?

Personally, I think that how useful an API is, and how RESTful it is, are entirely uncorrelated. Do take care though when describing your "sends-data-over-HTTP" application as "RESTful", because chances are, it might not be. Look out for anything with the word "REST" in it (if you ask nicely I might share the comments that I don't publish on this post) because REST has very specific criteria that can sometimes be difficult to adopt, and for some reason people interested in this subject seem to like to tell other people they are wrong a lot!

Published at DZone with permission of Lorna Mitchell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)