Skip to main content

Comparisons: APIs

  • REST (Representational State Transfer) is an architectural style that defines a set of constraints for creating web services. REST uses HTTP methods like GET, POST, PUT, and DELETE to manipulate resources, and it typically returns data in JSON or XML format. REST also relies on a stateless client-server model, meaning that each request is independent and doesn't rely on any previous requests.

  • GraphQL is another API architectural pattern that allows clients to specify the data they need, and servers to respond with that data. GraphQL enables clients to request specific data and receive only that data, reducing the amount of data transmitted over the network. GraphQL also allows clients to specify the shape of the data they want, making it more flexible than REST.

  • RPC, on the other hand, is more focused on procedure calls, with a specific focus on method invocations, parameter passing, and return values. Unlike REST and GraphQL, RPC is not tied to a specific transport protocol or data format, and can use a variety of formats such as JSON, XML, or binary. RPC has gotten more usage recently with blockchains and high-speed/high-volume messaging.

REST vs. GraphQL Checklist​

Answers indicating REST may be a better choice​

  • These recommendations are generalized, and may not be applicable to all designs.
  • Some of the REST recommendations are only slightly better, or depend on dev skills.

  • Is the application using simple CRUD operations on basic data structures?

    • REST API is better suited for simple CRUD operations and when the client doesn't need to have a lot of control over the data they receive.

  • Are a small amount of requests required and projected?

    • GraphQL excels at consolidating many requests. But REST's simpler interface is better suited to a low amount of simple requests.

  • Is the application deployed across multiple regions with other REST interfaces?

    • REST has some advantages for caching and multiregion distribution if there are existing interfaces. However, GraphQL services can also handle multi-region with some additional work.

  • Does the existing microservice architecture have REST in place?

    • If REST may be working fine in an existing architecture, there may be no compelling reason to switch to GraphQL.

  • Does the application require a high degree of scalability?

    • REST is is easier to use with caching services.
    • REST APIs are based on standard HTTP methods, which allows for easy caching of responses on the client side.
    • This can improve the performance of the application, especially for applications with a large number of read-only operations.
    • GraphQL may be more scalable in certain cases, as it reduces the number of requests needed to fetch data.

  • Are your devs more skilled and accustomed to REST interfaces, which have more usage and been around longer?

    • REST is a simple and well-established architectural style, making it easy to understand and implement. This can be particularly useful for small-scale projects or projects with a limited budget and timeline.
    • RESTful APIs are widely adopted, and many developers are already familiar with them. This can make it easier to find developers with experience working with REST APIs.

  • Does the application need to support offline synchronization?

    • REST may be slightly better for applications that need to support offline synchronization, due to slightly better caching.
    • However GraphQL can also handle this, albeit with slightly more memory usage for extra caching needs.

  • Does the application need to support push notifications?

    • REST may be better for applications that need to support push notifications, using WebSockets or long polling. GraphQL can handle this, but with a bit more setup. However, GraphQL can be used to subscribe to certain events, and when those events happen, the server would push the corresponding data to the client, who would then update the state accordingly. So if subscriptions are used GraphQL may be beneficial.

  • What type of data needs to be stored in the application?

    • REST is better for applications that require a variety of data types

  • Is the application expected to be used by a small subset of users or a large user base?

    • REST is better for applications with large user bases

  • What is the expected latency for data requests?

    • REST is better for compression and caching, while GraphQL can limit the response data size and GraphQL allows clients to make multiple queries in a single request. So both can be helpful - very slight edge to REST here, but depends on usage. Simpler defined queries REST, more complex GraphQL.

  • What type of analytics will the application need to provide?

    • REST is better for applications that need to provide analytics

  • Does the application require fine-grained access control?

    • REST may be easier for applications that need fine-grained access control, as it is easy to implement fine-grained access control using standard web security techniques such as SSL/TLS, OAuth, and JWT. These techniques allow for secure and flexible access control, and are widely adopted, making it easy to find developers with experience working with them.
    • GraphQL doesn't have a standard method for access control, but it could be achieved by adding the necessary authorization checks on the server side before executing a query. GraphQL also allows to define a schema, which could be used to define the authorization rules. This can provide fine-grained access control over the data, but it may require additional setup and configuration.

GraphQL may be a better choice​

  • Use as a conversation starter.
  • These recommendations are generalized, and may not be applicable to all designs.

  • Is the API mainly being requested for a mobile, "chatty" (many API requests) or IoT app?

    • GraphQL allows clients to request exactly the data they need. This can be particularly useful for mobile applications, as it allows the client to minimize the amount of data sent over the network.
    • GraphQL also allows clients to make multiple queries in a single request, which can reduce the number of round trips to the server.

  • What is the size and complexity of the data that needs to be handled?

    • GraphQL may be better for applications with complex data structures
    • Flexibility: GraphQL allows clients to request exactly the data they need. This means that the client can retrieve only the data that is relevant to them, rather than receiving a fixed set of data from the server. This can be particularly useful for applications with complex data structures, as it allows the client to navigate and access the data more easily.
    • Multiple Queries: GraphQL allows clients to make multiple queries in a single request, which can be useful for applications that need to retrieve data from multiple sources. This can reduce the number of round trips to the server and improve the overall performance of the application.
    • Nested Data: GraphQL allows clients to retrieve nested data in a single request, which can be useful for applications that have complex data structures with multiple levels of nesting. This can reduce the number of round trips to the server and improve the overall performance of the application.
    • Strongly Typed: GraphQL uses a schema to define the structure of the data, making it strongly typed. This can be helpful for applications with complex data structures, as it allows the client to know exactly what data to expect from the server.
    • Easy to Handle: GraphQL makes it easy for the client to handle data because of its flexibility in querying and its strong typing. It also makes it easy for the server to handle data because of its clear and expressive querying language.

  • What is the expected size of the user base?

    • GraphQL may be better for applications with a small user base

  • How often is the data updated?

    • GraphQL may be better for applications that require frequent data updates. GraphQL can be used to subscribe to certain events, and when those events happen, the server would push the corresponding data to the client, who would then update the state accordingly.

  • Does the application require a real-time connection between the client and server?

    • GraphQL may be better for applications that require real-time connections.
    • GraphQL subscriptions allow the client to subscribe to specific events, and when those events happen, the server pushes the corresponding data to the client, who can then update the state accordingly.
    • This allows for real-time updates without the need for the client to continuously poll the server for updates, which can reduce the load on the server and improve the overall performance of the application.

  • Does the application need to support multiple authentication methods?

    • GraphQL may be better for applications that require multiple authentication methods

  • Does the application need to support a variety of data sources?

    • GraphQL may be better for applications that require a variety of data sources

  • What is the estimated cost of development and maintenance?

    • GraphQL may be better for applications that require a lower cost of development and maintenance

RPC vs. REST API​

  • Lower overhead

    • RPC tends to have lower overhead than RESTful APIs because it uses a binary protocol like Protocol Buffers or Thrift that reduces the amount of data that needs to be transferred over the network.

  • Better performance

    • Because RPC has lower overhead, it can perform faster than RESTful APIs for certain types of applications. This can be particularly important in high-performance applications like gaming or finance.

  • Tighter integration

    • RPC can provide tighter integration between different components of an application because it uses a more structured approach to data exchange than RESTful APIs.

  • Simplified code

    • RPC can simplify your code by allowing you to define interfaces that automatically generate the necessary code for the client and server. This can reduce the amount of boilerplate code that you need to write.

  • Better support for stateful applications

    • Because RPC is a more structured approach to data exchange, it can be better suited for stateful applications that require more complex data exchange than RESTful APIs.

Here are five reasons you might choose REST APIs over RPC:

  • Platform independence

    • RESTful APIs are platform independent, meaning they can be used by any client or server that can make HTTP requests. This can make it easier to integrate different systems and technologies.

  • Better support for caching

    • RESTful APIs have better support for caching than RPC because they use HTTP caching mechanisms like ETags and Last-Modified headers.

  • Better support for hypermedia

    • RESTful APIs support hypermedia, which allows clients to dynamically discover and navigate resources within the API. This can make it easier to build flexible and scalable systems.

  • Easier debugging

    • RESTful APIs are easier to debug than RPC because they use a standard set of HTTP status codes and headers. This makes it easier to identify and fix issues with your API.

  • Better support for browser-based applications

    • RESTful APIs are better suited for browser-based applications because they use standard HTTP methods and headers that are supported by web browsers. This can make it easier to build web-based applications that can be accessed from any device.