- ✓REST APIs use standard HTTP methods and resource-oriented URLs to provide a stateless, cacheable interface that is well-suited to CRUD (Create, Read, Update, Delete) operations on well-defined resources.
- ✓GraphQL allows clients to request exactly the data they need, no more and no less, in a single request, solving the over-fetching and under-fetching problems that are common with REST APIs in complex or mobile-first applications.
- ✓gRPC uses Protocol Buffers and HTTP/2 to provide a high-performance, strongly-typed RPC (Remote Procedure Call) framework that is particularly well-suited to microservices communication and scenarios where performance is critical.
- ✓Event-driven APIs, such as those built with WebSockets or webhooks, enable real-time bidirectional communication between client and server, and are essential for applications such as live chat, collaborative editing and real-time data dashboards.
- ✓The right API architecture for a given project depends on factors including the nature of the data being exchanged, the performance requirements, the clients that will consume the API and the development team's existing skills and tooling.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Welcome back to The Study Podcast. We're closing out Unit 14 today by comparing different API architectures: REST, GraphQL, gRPC and event-driven approaches. Sam, understanding the landscape of API styles is increasingly important as the use cases for APIs become more varied.
Sam: Absolutely. REST has been so dominant for so long that many developers treat it as the obvious default choice for any API. But it's not always the best choice, and understanding the alternatives and when they're most appropriate is what separates a thoughtful API architect from someone who just applies the same pattern to every problem.
Alex: Let's revisit what REST does well and where it has limitations.
Sam: REST excels at building web APIs that expose clearly defined resources with standard CRUD operations. Its use of standard HTTP conventions makes it easy to learn, widely supported by tooling and straightforward to debug. Its statelessness makes it easy to scale horizontally. Where REST shows limitations: in applications with complex data requirements, like a social media feed that needs user information, post content, comment counts and reaction data all in one request, REST often requires multiple requests or a complex over-built single endpoint. The problem of over-fetching (getting more data than you need) and under-fetching (not getting enough and needing another request) is inherent to the resource-centric model.
Alex: And that's the problem GraphQL was designed to solve?
Sam: Precisely. In GraphQL, there's typically a single endpoint and the client describes exactly what data it needs in the request. A mobile app with limited bandwidth can request only the fields it needs. A dashboard that needs a complex aggregation of related data can request all of it in a single query. The server resolves the query against its data sources and returns exactly what was requested. This is genuinely powerful for client-driven applications, particularly mobile apps. The trade-offs are: higher complexity for the server to implement, a different mental model for developers familiar with REST and some complexity around caching, which is simpler in REST because responses are associated with specific URLs.
Alex: What about gRPC?
Sam: gRPC uses Protocol Buffers, a compact binary serialisation format, and HTTP/2 to provide high-performance, strongly-typed remote procedure calls. It's significantly faster and more efficient than REST with JSON for service-to-service communication because binary serialisation is more compact and faster to parse than JSON. The strong typing through Protocol Buffer schemas also provides better developer tooling and clearer contracts between services. Its limitations are: higher implementation complexity, less human-readable (you can't just inspect a gRPC message in a browser), and less well-supported in web browser contexts.
Alex: And event-driven APIs are quite different from all three of these?
Sam: Yes. Rather than a client requesting data and waiting for a response, event-driven systems push updates to consumers when something happens. WebSockets provide a persistent bidirectional connection between client and server, enabling real-time messaging and collaborative applications. Webhooks allow a server to push notifications to a consumer's URL when an event occurs. These approaches are essential for applications where real-time updates are important: live chat, collaborative editing, trading platforms, real-time dashboards.
Alex: How do you choose between all these options?
Sam: It comes back to the specific requirements. What kind of clients will consume the API? What are the data access patterns? Are low latency and high throughput the priority or developer accessibility and standardisation? In many real applications, the answer is more than one: REST for the public-facing API, gRPC for internal service communication, and WebSockets for real-time features.
Alex: Excellent synthesis. Thanks, Sam. We'll start Unit 15 on work-based learning next.