Comment by frik | Hacker News Reader

Comment by frik | Hacker News Reader

I would say there is no need for this.

JSON/REST are beloved because it's simple and just works. Originally XML itself was simple too with just DTD as "Schema".

BUT then all the additional standards like XMLSchema, XSLT, XML-RPC/SOAP turned it in an ugly duck.

  JSON API is extracted from the JSON transport implicitly 
  defined by Ember Data's REST adapter. 
  http://jsonapi.org/about/

As JSON-API comes from the Ember.js camp, I remember the Ember vs. Angular discussions on HN 1-2 years ago. Google Trends shows Ember.js has gone nowhere. https://www.google.com/trends/explore#q=AngularJS%2C%20Ember... (and now there is also React). So I guess the "Ember.js way" to do things failed. At some point we should learn from history, and not turn JSON into SOAP/WSDL - https://xkcd.com/927/ .

XML-RPC/SOAP and/or many other remote procedure call transport techniques failed in in the long term and are a big pile of legacy mess (CORBA, DCOM, RMI, SAP RFC, .NET Remoting, XML-RPC, etc.): http://en.wikipedia.org/wiki/Remote_procedure_call

> 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).

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.

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.

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.

> 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.

I'm definitely in the lenient camp on a [simple -- complex] scale. So, I agree JSON/REST are simple and just works, for most tasks. That's certainly how I've used the two technologies mostly.

But I definitely see some benefits with json-api. Here are two:

1. When writing large single-page apps in JS, client <-> backend communication will need some structure. Could be a few project-internal guidelines, or something like json-api.

2. Client frameworks and backend frameworks are often separate projects (e.g. Django/express/sinatra server-side or React/Backbone/Mithril client-side). It's helpful with a standard to converge on for authors of backend json/rest serializers, and data adapters client-side.

I'm not expert of RPC's, but I'm pretty sure it's something quite different from jsonapi.

Your google trends search is very deceiving as you used different kinds of terms "ember.js vs angularjs".

here is the trend for "ember.js vs angular.js" http://www.google.com/trends/explore#q=ember.js%2C%20angular...

I used the official names, or at least what Wikipedia lists as official name: http://en.wikipedia.org/wiki/Ember.js , http://en.wikipedia.org/wiki/AngularJS. Adding "React" (Facebook's React) is even more difficult.

These kinds of searches are hard to get right. The name for the ember project is "ember", have a look at the website. The search term "ember" is too general though for comparison.

I guess the point is that google trends is often a bad metric.

Reply on news.ycombinator.com