Skip to content

APIs - REST vs SOAP vs RPC vs GraphQL

APIs: REST vs SOAP vs RPC vs GraphQL#

RPC#

  • Local clients sends commands to a remote server
  • Stubs convert client and server requests and responses
  • XML-RPC and JSON-RPC - Google made general purpose RPC as gRPC
  • Apache Thrift and Twitter Twirp use gRPC for internal microservices communication
  • RPC uses short lightweight messages that go easy on the network
  • Used verbs to manipulate the service, eg. getCustomerAccount

SOAP#

  • Simple Object Access Protocol
  • Microsoft created in 1999
  • Every soap message has an envelope, header and body (and a fault when it fails)
  • SOAP ws-security encrypts messages
  • SOAP can chain messages for complex transactions with multiple parties
  • SOAP is very complex and verbose
  • Used verbs to manipulate the service, eg. getCustomerAccount

REST#

  • Representational State Transfer
  • Resource based
  • Keeps verbs to a minimum: HTTP methods
  • Client-server autonomy: as long as the API interface does not change, the client and server can change the database or internals
  • Uniform interface: 1 naming convention or end-point format (endpoint is uri with http method)
  • Layered system architecture: client knows nothing of server architecture - intermediary or end server
  • Stateless interactions: each request is taken as new (opposite of soap but soap allows both)
  • HTTP caching
  • Code on demand
  • Can be chatty - getting too much info for the client
  • Shallow learning curve

GraphQL#

  • In 2015 - Facebook got tired of REST overfetching data
  • Single request - returns all inclusive reply
  • Single endpoint
  • Client can customise what is returned with a schema
  • Steep learning curve

Event driven architecture - subscribing to events instead of polling of request-response. Event producers and consumers don’t directly depend on each other. They act asynchronously and execute operations when needed.

Sources#