Re: How much REST should your Web API get?

Jan,

I remain a strong proponent of the idea that it is more fruitful to aim at
> rethinking the problem to fit a sound paradigm rather than to blame the
> paradigm for not fitting the problem (one's perceived view of it, that is).
>

But when the paradigm isn't intended to solve a given problem, do you think
we should force the problem to fit into the paradigm?

REST was never designed to solve all software architecture problems. That's
quite the opposite and what makes it so powerful to scale the web of
hypermedia documents.

Two concrete points:
>
> I don't buy the efficiency argument regarding discovery and granularity of
> messages - unless you ignore caching and the possibility to tailor
> representations for specific devices.
>

You could also add HTTP compression to the mix. I'm a fan of HTTP caching
and content negotiation as well. The "Web API" style proposed fully
leverages those features.


> You write about the 'Web API style' "requires coordination between clients
> and servers when changes are deployed" - doh... this eliminates *the*
> (**the**) primary benefit to apply REST.
>

Exactly, but if you ship a native mobile app or a connected hardware device
with no hypermedia capability at all (think about a dumb sensor), you
definitely need to coordinate the clients and servers even though you are
fully and properly using HTTP. This is why the vast majority of so-called
web APIs are versionned and based on stable URIs and representations
structures. They can't always afford to dynamically discover the user
interface.

You could say that native apps aren't needed and could be re-developped as
HTML 5 apps, but this isn't always possible or desirable.


> Aside from systems that focus on sending fine grained control messages
> around in (near) realtime, I have yet to see a case where REST does not
> shine due to performance, scalability and the ability to decentralize
> management of the deployment and release cycles.


Again, my point is to take the best of what REST brings but not try to
apply it in cases where a rich hypermedia client is available, but isn't so
uncommon. I'm just trying to do REST justice otherwise we'll get a
backslash when people finally realize that the vast majority of REST
endpoints/APIs/etc. can't be used in a dynamic way like HTML is used by web
browsers.

Best regards,
Jerome