I just wrote this email on a private mailing list and thought it may make sense to share it. The context of the discussion was overuse of the term “REST” in a document discussing an HTTP API:

REST is a set of architectural principles. REST describes how state flows and describes the shape of relationships between the parties in a distributed system. HTTP is a protocol with a variety of stacks supporting it, and the REST principles were born out of developing HTTP. There could, in theory, a broad variety of protocols that also embody REST architecture, but  there are, in fact, very few (if any) that aren’t just variations of HTTP.

“The client sends …”, “The server receives …”, “The server provides an interface for …” are all statements about implementation and, thus, HTTP. It commonly starts making talking about REST specifically when debating whether a system is actually following the principles according to the 5.3.3 “Data View” section in [1], since everything up to that point in Fielding’s dissertation you get generally for free with HTTP. 

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Bottom line: HTTP APIs are HTTP APIs. REST is about how things hang together. The terms aren’t interchangeable. In most technical discussions about interfaces or methods or URIs and most other implementation details, HTTP API is the right term.

Categories: Architecture

Friday, April 13, 2012 7:24:05 PM UTC
I have been using the same terminology at work to avoid religious debates. In the end it's about the usability of an API, as that what makes it a succes, not whether it is truly REST or not...
Bjorn Coltof
Saturday, June 2, 2012 8:57:02 PM UTC
i use http api mostly. It's little weird for some guys but works for me. The only issue is security and once you take care of it, it's easy. I use SSL ofcourse.
Saturday, June 2, 2012 11:02:29 PM UTC
Yeah i use api's also. Helped me a lot!
Comments are closed.