5 Powerful Alternatives to REST APIs (2018 Update)

There are many problems with REST APIs that make them expensive, tedious and error-prone, but RESTful APIs are everywhere. So much so that you'd be forgiven for thinking there are still no competing alternatives in 2018. What are the most viable alternatives to REST APIs, you ask?

If I was building a shiny new API in 2018, my focus would primarily lie on the unpararelled efficiency of graph queries and flexibility to rapid changes. GraphQL is much more mature than Falcor at the moment - a clear leader in this regard. Your API will be ready and stable within a few months due GraphQL contraints of GraphQL. If however I was building an API for data streaming apps requiring real time capabilities, Falcor's paths and references give it a considerable edge over GraphQL because of the ability to merge separate data chunks and live updates. Nothing would beat the gripping simplicity of modeling a single virtual JSON object on a server running Node.js then.

Lets see what this means by exploring the five most popular alternatives to building RESTful APIs in 2018:

  1. GraphQL APIs
    • checkBased on tree data model.
    • checkThe most mature alternative to rest at the moment.
    • checkClients fetch data from a single endpoint.
    • checkClients make fewer more efficient requests.
    • checkNo underfetching or overfetching client requests.
    • checkEasier error handling with verbose error messages.
    • checkAccomodates faster iteration cycles.
    • checkMutations, fragments and type system create high UX.
    • checkReduces time to market by giving developers most for less.
    • checkDoes not take advantage of HTTP caching.

  2. Falcor APIs
    • checkBased on graph data model.
    • checkFalcor is the most dynamic alternative at the moment.
    • checkRetains the idea of a path from REST.
    • checkRetains the idea of references from REST.
    • checkGood fit for data streaming apps.
    • checkGood fit for live updates apps.
    • checkEasy caching and data consistency.

  3. gRPC APIs
    • checkAccepts and return Protobuf messages.
    • checkUses the HTTP/2 protocol.
    • checkUses programming language syntax with messages.
    • checkA good fit for data streaming.
    • checkProtobuf, unlike JSON, requires a message format.
    • checkA perfect for for microservices architectures.
    • checkNot as mature or widely supported.
    • checkgRPC Gateway uses REST which erodes perceived benefits.

  4. JSON-Pure APIs
    • checkUse a single transmission method to send a request.
    • checkSeparate data from transmission
    • checkOnly one response code to confirm receipt
    • checkEasy to debug, payloads have domain-specific vocabulary
    • checkCan be shared between transmission channels
    • checkNot statically typed.

  5. oData APIs

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

  • Falcor APIs

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

  • gRPC APIs

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

  • Pure JSON APIs

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

  • OData APIs