GraphQL vs REST for Travel APIs: Our Decision
We chose REST with well-designed resources over GraphQL for travel data. Here is the analysis — query complexity, caching, tooling, and AI agent compatibility — behind our call.
Every API team has the GraphQL vs REST debate. We had ours. It consumed a full week of discussion, a decision matrix with weighted criteria, and several heated disagreements. In the end, we chose REST. Here is the analysis that got us there, including the areas where we think GraphQL would have been the better choice.
This is not a "REST is better than GraphQL" argument. It is a "REST was better for our specific domain and our specific consumer base" argument. Your answer might be different.
Travel data is deeply nested and volatile
Travel data has a specific shape that affects the GraphQL vs REST decision.
A flight search response includes flights, which contain segments, which contain legs, which contain layover details at connecting airports. Hotels include properties, room types, rate plans, cancellation policies, and photo galleries. Bookings reference offers, travelers, payment information, and documents.
This deep nesting plays into GraphQL's strength: clients can request exactly the fields they need at each level. A mobile client that only needs airline name, price, and departure time can avoid fetching the full segment breakdown, layover details, and amenity lists.
But it also plays into GraphQL's weakness. An unconstrained GraphQL query against this deeply nested data can be enormously expensive. A query that selects every field at every level of a flight search response effectively forces the server to join across multiple data sources, aggregate provider responses, and serialize a massive payload. Without careful query depth limiting and cost analysis, a single GraphQL query can bring down a server.
REST avoids this by design. Each endpoint returns a fixed shape. The server controls what data is included. The cost of each endpoint is predictable and measurable. We can set rate limits that accurately reflect the resource cost of each call because the resource cost is the same every time.
Caching is dramatically simpler with REST
REST resources with stable URLs are trivially cacheable at every layer of the stack. The browser, the CDN, reverse proxies, and the application server all understand HTTP caching. A `GET /flights/flt_abc123` response can be cached with standard `Cache-Control` headers and invalidated with standard mechanisms.
GraphQL queries are POST requests to a single endpoint. They are not cacheable at the HTTP level by default. You need specialized GraphQL caching infrastructure (normalized client caches, persisted queries, or custom CDN configurations) to get the same caching behavior that REST gets for free.
For a travel API where the same flight offer might be requested multiple times by the same client (once for the search results page, again for the detail view, again for the booking confirmation), cache hits dramatically reduce latency and load. REST gave us this without additional infrastructure.
AI agent compatibility
This factor was not on most GraphQL vs REST comparison matrices when we made our decision, but it turned out to be one of the most important.
Our platform serves AI agents that make API calls using tool-calling interfaces. Each tool has a JSON Schema definition that describes the endpoint, its parameters, and its response shape. LLMs use these schemas to decide which tool to call and how to construct the request.
LLM tool-calling accuracy is measurably higher with discrete REST endpoints than with freeform GraphQL queries. A REST tool definition says "call `GET /flights/search` with these parameters and you get back this response shape." The LLM has a clear, constrained action to take.
A GraphQL tool definition would need to say "construct a GraphQL query that selects the fields you need from the flights type." The LLM now has to generate a syntactically correct GraphQL query, choose the right fields from a potentially large schema, and handle nested object selection. More degrees of freedom mean more opportunities for hallucination and incorrect queries.
Our agent system has 70+ tools, each mapped to a specific REST endpoint with a focused JSON Schema definition. This clean mapping between tools and endpoints makes the agent reliable. With GraphQL, we would have needed either one tool with an enormous schema (hard for LLMs to navigate) or many tools that each construct different GraphQL queries (fragile and hard to maintain).
Where GraphQL would have won
I want to be honest about the tradeoffs. There are areas where GraphQL is genuinely better.
Mobile bandwidth optimization. A mobile client on a slow connection downloading a flight search response does not need every field. With REST, it gets everything. With GraphQL, it could request only the fields it renders. We addressed this partially with response compression and are exploring field selection parameters, but GraphQL handles this more elegantly.
Frontend development velocity. GraphQL lets frontend developers add new fields to their queries without waiting for a backend API change. With REST, if the frontend needs a new field in a response, it is a backend change, a review, and a deployment. GraphQL shifts that coordination cost to zero. For teams with separate frontend and backend teams, this is a significant productivity gain.
Schema introspection. GraphQL's type system and introspection capabilities are genuinely excellent. The schema is self-documenting, tools can generate types automatically, and the development experience in a GraphQL IDE is hard to match. Our REST API achieves something similar through OpenAPI, but it requires more tooling and discipline.
The decision framework
If you are making this choice for your own API, here are the five questions that shaped our decision:
- Do your queries have predictable cost, or can clients construct arbitrarily expensive queries? If the latter, GraphQL requires query cost analysis infrastructure.
- Is HTTP-level caching important for your performance goals? REST gets it for free. GraphQL requires extra work.
- Will AI agents consume your API? REST endpoints map more cleanly to tool definitions than GraphQL query construction.
- Do your clients need fine-grained field selection? GraphQL excels here. REST requires custom solutions.
- How separate are your frontend and backend teams? If they are different teams with different deployment cycles, GraphQL reduces coordination overhead.
For us, the answers pointed to REST. Predictable query costs, important caching, heavy AI agent usage, acceptable bandwidth overhead, and a small team that deploys frontend and backend together. Your answers might point the other way, and that is fine. The decision is about your constraints, not a universal truth.
We chose REST and built it well. We invested in consistent resource design, comprehensive OpenAPI specs, type-safe SDKs, and detailed error messages. A well-built REST API competes with GraphQL on developer experience. The protocol is simpler. The ecosystem is more mature. And for our specific use case of serving both human developers and AI agents with travel booking data, it was the right call.
Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.