
Classification of HTTP APIs - sinzone
http://www.nordsc.com/ext/classification_of_http_based_apis.html
======
extension
So what REST really boils down to, versus the next best thing, is creating
file types instead of protocols/APIs. And its value is based on the
presumption that file types will be more stable and versatile, and less
coupled to any particular service.

While I would agree with that, I question how often a developer actually has a
choice of whether or not to go with REST. It seems to solve an entirely
different problem than an API: REST is for public standards, not proprietary
services. You certainly need to know which you are making before you worry
about what architecture to use.

If the Twitter API were RESTful, it would be OStatus, and that's obviously not
what it's supposed to be.

~~~
masklinn
> So what REST really boils down to, versus the next best thing, is creating
> file types instead of protocols/APIs.

And hypermedia as the application state driver. That's actually the main
component of a restful API, though the one most often missed.

> It seems to solve an entirely different problem than an API: REST is for
> public standards, not proprietary services.

Why could you not use REST for proprietary services?

~~~
loup-vaillant
> _Why could you not use REST for proprietary services?_

Proprietary services can be entirely controlled: proprietary server,
proprietary client, proprietary protocol. You don't mind if they are coupled,
just update them at the same time. Also, proprietary protocol often don't come
with the long term vision that characterize open file formats and protocols.
The cash has to flow soon, then for a few years. Beyond that, all bets are
off.

So it's not that you couldn't, but rather that you wouldn't. I guess.

~~~
masklinn
> You don't mind if they are coupled

Of course you do. They may be under the control or purview of different team
members (or teams, or contractors), and coupling always increases maintenance
costs.

> just update them at the same time.

Or don't couple them and update them when you need to.

> Also, proprietary protocol often don't come with the long term vision that
> characterize open file formats and protocols. The cash has to flow soon,
> then for a few years. Beyond that, all bets are off.

Right, so you would not use REST for proprietary services because proprietary
services are by definition moronic in design and intent?

Sounds great.

~~~
extension
Not moronic, just smaller in scope. Media types require considerably more work
to design than APIs, as is often noted by REST proponents. The guy who
invented REST calls it "engineering on the scale of decades". If You Ain't
Gonna Need That then you're wasting a lot of time by doing it that way.

