Over a million developers have joined DZone.

Five Clues That Your API isn't RESTful

DZone's Guide to

Five Clues That Your API isn't RESTful

· Performance Zone ·
Free Resource

Built by operators for operators, the Sensu monitoring event pipeline empowers businesses to automate their monitoring workflows and gain deep visibility into their multi-cloud environments. Get started for free today.

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!

Download our guide to mitigating alert fatigue, with real-world tips on automating remediation and triage from an IT veteran.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}