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