API Paradigms

REST, GraphQL and gRPC (SOAP and webhooks as well but less popular)

REST

set of loose standardization/guidelines for APIs
JSON is the most common data format for REST

requires client-server architecture
stateless (to facilitate horizontal scaling as server does not need to manager or update session state or cookies)

Issues with REST

Overfetching

when client receives more data than nesessary leading to unnecessary consumption of network resources

Underfetching

when endpoints are too narrowly defined, and requires multiple network calls to fetch all the data

GraphQL

built on top of HTTP (POST requests)
body includes exactly what resources we want from the server
main motivation is to mitigate over/under-fetching issues

Operations

queries: utilised to retrieve data

mutations: for modifying data on the server

Issues

built on HTTP POST and hence are not idempotent and hence are very hard to be cached precisely vs REST apis
- idempotent: calling req multiple times will lead to different results

gRPC

google remote procedure call
need HTTP/2
- provides bi-directional communication, or multiplexing for multiple messages over a single TCP connection and server push.
cant use directly from browser as it needs some fine grain control over HTTP/2 that browsers typically does not provide
server to server communication
much faster than REST
- because they are sent using Protocol Buffers instead of JSON

Protocol Buffer

language-neutral, platform-neutral extensible mechanism for serializing structured data. (binary -> much smaller data format)

Issues with gRPC

newer and has a lot less tooling around it
difficult for dev
no HTTP status codes, need own custom error handling defined on server-side