Pure JSON APIs
I write on GraphQL extensively on this blog. Because I use it alot.
GraphQL is data query language with a full spec. The language is front and center.
There is no getting away from it.
The language spec determines the validity of the schema in graph queries.
It is strongly typed. Declarative schema defines relationships between objects.
Since being open-sourced by Facebook it has gained some considerable traction over both Falcor and gRPC.
GraphQL continues to enjoy popular adoption since being popularly adopted by Github (now being bought by Microsoft).
GraphQL has the best developer experience of all five options because it has a polished query language, complete with type syntax.
This makes it more practical for most applications.
For Falcor, the language is not nearly as prominent as GraphQL.
Falcor has not enjoyed popular adoption on the level of GraphQL since being being open-sourced by Netflix.
It tends towards being perceived as part of a larger stack used by Netflix.
Falcor represents your data in one huge JSON object.
It retains the idea of a path from REST APIs. The path is used to traverse the huge JSON Object with a cleaner faster and more decalarative API.
It retains the idea of references from REST APIs. Because JSON Objects are use a tree format, Falcor graphs the Objects with references, esentially creating cycles.
Paths and References make Falcor a perfect match for realtime applications because it can easily reference and match data in sent in separate chucks. This translates to an incredible ability to merge live updates as they stream in.
Again because the data comes identified with references, caching and consistency is so much easier in Falcor, than say GraphQL.
Falcor is less prescriptive and more dynamic than GraphQL because it lacks strong type is not a QL.
While most both GraphQL and Falcor work on JSON, gRPC accepts and returns protocol buffer (protobuf) messages.
Protobuf is far more efficiently packed than JSON, but it is not a textual format.
When you compress JSON, you lose the textual benefit.
While REST depends heavily on the older HTTP/1.1 protocol, gRPC strictly enforces the HTTP/2 protocol.
Unlike REST which is intimately tied with the HTTP protocol, gRPC borrows its model directly from programming languages. Data structures such as functions and methods are heavily employed.
Building from programming languages, gRPC autogenerates the client libraries used for interfacting with the API.
Like Falcor, gRPC is a good fit for data streaming and live update apps.
Unlike Falcor, it's streaming features flow more from taking advantage for HTTP/2 streams than inherent design.
gRPC sends strongly typed messages that are converted from protobuf instead of JSON. Messages must adhere to a predefined structure designed to reduce performace overheads and the possibility of errors.
It is as widely supported by all major browser as the other alternatives. It thus mostly used for intranets rather than public facing APIs. There is however a gRPC Gateway that uses REST to expose APIs publicly.
Using gRPC with a gateway however however,erodes all its benefits.
JSON-Pure APIs separate message(content and data) and tranmission channels.
All warnings, errors and data is placed in separate JSON request payloads.
The confusion of multiple HTTP codes is averted because they only confirm message receipt with a HTTP - Ok
They are almost always faster and more reliable than REST APIs because of this.
They easy to debug. Transactional data easily be found in JSON payload contains single domain specific vocabulary.