[dgeb]

> JSON/REST are beloved because it's simple and just works.

There is no consensus on the details of "REST". Every implementation has its subtle quirks and solutions to the same basic problems. Every client library must be customized to adapt to these differences. Since the fundamental aspects aren't agreed upon, there is little chance of defining compatible features at a higher level.

On the other hand, the value proposition for JSON API is rooted in consensus [1]

[1] https://news.ycombinator.com/item?id=9281102

> As JSON-API comes from the Ember.js camp

JSON API has been proven in many languages and frameworks. The JSON API team is diverse and has only one member on the Ember core team (@wycats). More importantly, JSON API has been influenced by hundreds of contributors with diverse backgrounds and specialties.

At this point, JSON API is pretty far from its original extraction from Ember Data. It has come full circle to the point that a JSON API Adapter is being written from scratch for Ember Data (and is now almost fully compatible).

[tekacs]

> On the other hand, the value proposition for JSON API is rooted in consensus [1]

> JSON API has been proven in many languages and frameworks. The JSON API team is diverse and has only one member on the Ember core team (@wycats). More importantly, JSON API has been influenced by hundreds of contributors with diverse backgrounds and specialties.

CORBA (one of the cited failed examples above) is notable for having been rooted in consensus. It pulled together dozens of use-cases from all over industry... and became a giant, hulking, overly complex, unpleasant-to-use mess.

[ForHackernews]

I guess I'm confused then. If I wanted a complicated standard but one with broad consensus and lots of library support behind it, why wouldn't I just use XML-RPC? Other than not being XML, what does JSON API offer? Because at first glance, it looks just about as verbose and unfriendly as XML-RPC to me.

[LoSboccacc]

Json-rpc it's what you get anyway most of the time since very few have a clue of what rest is. Not that is a bad design by itself, many of them are concise and workable without being rest.

What I am concerned mostly is the added overhead of fitting everything under a single standard. Sometime you need state aware api, sometime you need data retrieval api, sometime you need to expose a remote interface to constraint manipulating objects with server side rules.

Why it all has to be a standard escapes me. You mostly get absurdly convoluted operation when you try to fit one model under another.

[dgeb]

JSON API adheres to RESTful principles and constraints: it uses HTTP verbs to fetch and manipulate resources and provides allowances for hypermedia. XML-RPC is neither RESTful nor supportive of hypermedia and has no place in building a REST API.