> Markdown version of [/videos/100247-rest-graphql-grpc-and-more-a-comparison-of-modern-api-styles?t=787](https://www.wearedevelopers.com/videos/100247-rest-graphql-grpc-and-more-a-comparison-of-modern-api-styles?t=787). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# REST, GraphQL, gRPC, and more: A comparison of modern API styles

Is REST holding your scaling platform back? Discover exactly when to choose GraphQL, gRPC, or OData based on real-world trade-offs rather than technical hype.

- **Speakers:** [Florian Bader](https://www.wearedevelopers.com/@florian-bader)
- **Event:** World Congress 2026 Europe
- **Published:** July 10, 2026
- **Duration:** 30:16
- **URL:** https://www.wearedevelopers.com/videos/100247-rest-graphql-grpc-and-more-a-comparison-of-modern-api-styles

## Summary

Building modern web platforms requires selecting the optimal API style, which becomes complicated as platforms scale to support web frontends, mobile devices, background services, and enterprise BI tools. This presentation explores the trade-offs between REST, GraphQL, OData, and gRPC using a real-world IoT telemetry scenario to illustrate when and how to implement each approach.

While REST remains the standard for simple CRUD operations—often documented via OpenAPI or enhanced with HATEOAS—it can suffer from over-fetching and under-fetching payload data. GraphQL solves this by allowing flexible, client-driven queries, though it introduces backend complexities like the N+1 problem (mitigated by data loaders) and caching challenges. For enterprise data access and integration with tools like Excel or Power BI, OData provides highly optimized, standardized querying. Meanwhile, gRPC shines in service-to-service communication, utilizing HTTP/2 and Protobuf for efficient, binary-based remote procedure calls with strict schema-first contracts.

To deliver live UI updates without hammering databases via polling, teams should migrate to push-based mechanisms like WebSockets, server-sent events, or GraphQL subscriptions, optionally using frameworks like SignalR to abstract transport and horizontal scaling. Ultimately, "trade-offs are more important than any technical hype." Rather than standardizing on a single emerging technology, architects should select approaches based on specific consumer needs, non-functional requirements, and developer operational readiness. When adopting multiple interfaces, it is crucial to centralize data retrieval and business logic beneath the varied API facades.

**Keywords:** modern api styles, rest over-fetching solutions, openapi specification linting, hateoas hypermedia navigation, graphql n+1 problem mitigation, data loader batching, graphql subscriptions, odata enterprise integration, grpc service-to-service operations, protobuf schema versioning, websocket real-time updates, server-sent events, signalr transport abstraction, asyncapi event-driven specification, api facade architecture

## Chapters

1. **Overview of modern API styles and the IoT scenario** (00:03) — A comparative look at modern web API options through a baseline IoT telemetry architecture.
1. **Modeling resource APIs with REST and OpenAPI** (02:51) — How modeling resources with REST and OpenAPI works despite inherent over-fetching limitations.
1. **Solving data fetching demands with GraphQL** (07:19) — How GraphQL allows client-driven queries to reduce over-fetching while introducing complexities like the N+1 problem.
1. **Standardizing data access schemas with OData** (13:07) — Utilizing OData for highly optimized, standardized queries and batch operations favored by enterprise data tools.
1. **Establishing internal service communication with gRPC** (16:56) — Leveraging gRPC and Protobuf for highly efficient, strongly-typed binary communication between internal microservices.
1. **Implementing real-time telemetry updates and subscriptions** (21:53) — Transitioning from inefficient polling to real-time event communication using WebSockets, GraphQL subscriptions, and SignalR abstractions.
1. **Evaluating and selecting appropriate API architectures** (25:35) — How to adopt the right API architecture depending on consumer constraints, performance requirements, and operational reality.

## Related Moments

- [Choosing the right API protocol today](https://www.wearedevelopers.com/videos/1683-rest-in-peace-what-does-the-api-protocol-of-the-future-look-like-or-do-we-have-it-already) (from "REST in Peace? What does the API protocol of the future look like? Or do we have it already?")
- [Evolution of API interfaces toward declarative data fetching](https://www.wearedevelopers.com/videos/1054-graphql-does-it-replace-sql-rest-or-something-else) (from "GraphQL: Does it replace SQL, REST or Something Else?")
- [Evaluating benefits and drawbacks of common API formats](https://www.wearedevelopers.com/videos/1195-the-great-api-debate-rest-graphql-or-grpc) (from "The Great API Debate: REST, GraphQL, or gRPC?")
- [Exploring alternative data retrieval methods beyond standard REST patterns](https://www.wearedevelopers.com/videos/1675-api-some-rest-and-http-right-right) (from "API = Some REST and HTTP, right? RIGHT?!")
- [Comparing GraphQL capabilities against the JSON API standard](https://www.wearedevelopers.com/videos/33-api-design-getting-started) (from "API Design - Getting Started")
- [Core concepts and categories of APIs](https://www.wearedevelopers.com/videos/1683-rest-in-peace-what-does-the-api-protocol-of-the-future-look-like-or-do-we-have-it-already) (from "REST in Peace? What does the API protocol of the future look like? Or do we have it already?")

## Related Articles

- [Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)](https://www.wearedevelopers.com/magazine/745-why-event-driven-architecture-isn-t-about-speed-and-when-you-actually-need-it)
- [Dev Digest 139 - Soft and hard queries](https://www.wearedevelopers.com/magazine/487-dev-digest-139-soft-and-hard-queries)
- [Web Development Best Practices: What The Data Tells us](https://www.wearedevelopers.com/magazine/84-web-development-best-practices-what-the-data-tells-us)
- [Navigating the AI Shift](https://www.wearedevelopers.com/magazine/629-navigating-the-ai-shift)

## Related Jobs

- [Senior Software Engineer, Client Apps Platform](https://www.wearedevelopers.com/jobs/ext/1773893-senior-software-engineer-client-apps-platform) at **GitHub**
- [Staff Software Engineer](https://www.wearedevelopers.com/jobs/ext/1425755-staff-software-engineer) at **GitHub**
- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/267591-principal-software-engineer) at **Twilio**
- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/146806-principal-software-engineer) at **Twilio**
- [Mid/Senior Full-Stack Engineer (Web-first)](https://www.wearedevelopers.com/jobs/ext/1210833-mid-senior-full-stack-engineer-web-first) at **SMG Swiss Marketplace Group**
- [Principal Software Engineer](https://www.wearedevelopers.com/jobs/ext/115163-principal-software-engineer) at **Twilio**