REST in Peace? GraphQL vs REST in the Age of Agentic AI | apidays India 2026

All right. Uh, hi, welcome everyone. Uh, first of all, it's a full house. I didn't expect so many people to turn up. Uh, but thanks for making it. Uh, so, uh, by the way, when I came up with this, uh, title, Nar gave me feedback to make it a bit less confrontational or, you know, controversial. Uh, I told him, yes, I'll do it. But then you know I completely skip that. Uh but anyway so the topic that we are going to be talking about is uh rest or graphql which is better for agentic use cases. So before I I sort of share you know my view or experience with this I just wanted to ask the audience do you guys have any view on which is a better fit for agent use cases? Anyone? Uh how many people think rest is a better fit? One person, one brave person in the GraphQL track. Two, three. Okay, slowly hands are coming up. How many say GraphQL is a benefit? Okay. And some people might be thinking neither of them are, which is also a fair answer. >> GraphQL is better. >> Oh, okay. Okay. Right. Right. Yeah. So, we'll find out hopefully. Yeah. So, uh I'll just introduce myself. My name is Santos. I'm part of IBS. I'm not part of the engineering organization. I'm part of the product management uh division. uh when it comes to APIs, my key role is to define the API strategy for our product, right? So what that means is uh where should be investing our next set of dollars uh when it comes to improving our API product offering. So the way the reason this uh question came up is because the the same question got asked to me right uh we currently we have uh oh by the way let me just introduce the company also uh IBS software we make uh software for the travel industry. So when I say travel industry, we're talking about airlines, cruise lines, hotels, loyalty programs. Uh just to uh drop some names. If are you all familiar with Emirates? Uh Emirates and their loyalty program. Skywards for instance that runs on our software, right? Or a lot of the you know airlines reservation systems they run on our software. I am part of the cruise division. We make reservation system for cruise lines. So uh our customers use our rest APIs to essentially expose their uh book uh their inventory data to travel agents and travel agents use those APIs uh and when I say travel agents it would also include OTAA. So for instance booking.com, Expedia etc. The way they are getting you know the hotel inventory or the airline inventory or cruise inventory is through APIs that we are exposing. So our core API product offering is a set of rest APIs and that has been working phenomenally well for us. Uh but just like most companies uh we are also facing pressure from our board to start investing in agentic solutions right as part of our product. So when [clears throat] you look at building an agentic solution as you all know tool calling is a key part of it. So the question that was asked was okay you know these agents that we're going to build they're going to require APIs. we already have APIs you know is that is that enough like do we need to invest anything more to make those APIs better so that's the question that got asked to me and uh frankly I did not have the answer and when you don't have the answer the first thing that you do these days is to just ask AI right so I opened up claude gemini chat GPT asked all of them the same question uh so these screenshots were taken maybe last week but when I I asked the original question a year back I got wildly opposite answers by the way so the latest view according to AI is most of them okay you can't see it clearly but it seems AI seems to prefer rest right whereas a year back AI was preferring graphql so [clears throat] I was also kind of in a confusion I thought okay you know what I have to find out the answer myself and the only way that I can do it is let me come up with a benchmarking experiment where I'll set up a backend I'll build two sets of APIs a set of rest APIs a set of graphql APIs connect them to the same agent ask the same question and just see who wins, right? Fairly straightforward setup. So, this is what the experiment looked like. Uh yeah, I mean I can make it sound complex but it's actually fairly simple. There's a Postgress database. I've used Superbase, you know, cuz you have free tires in there. And I've created a data model which is essentially a list of fabricated companies, a list of products and subscriptions that each company has to the product. And uh Postgress comes with you know plugins and adapters to spin up APIs. So I used that to set up a graphql endpoint as well as a set of rest APIs against all of those entities. Connected them to a app that I built using streamllet and built agent there and I'm using open openai's GPT4 model to uh for the LLM part. Yeah. So [clears throat] if I deep dive into the setup, this is what the data set looks like. Uh there are set of products, companies, subscriptions, users, uh usage of the products. Uh fairly simple, not at all comparable to a real world production sort of data set, but this was just to get started, right? Uh and in terms of APIs, so these are the tool definitions. I don't know, are you all familiar with what a tool definition is in the world of agents? Yeah. Yeah. So tool definition is essentially your sort of English written down definition of your API that you feed as context to your uh AI agent, right? So I had the APIs in the back end and then I wrote some uh tool definition both for REST API and uh the GraphQL endpoint. Uh the UI layer uh I built it using Streamlit. I'm not a UI. I'm not an engineer at all. So Streamlit is is very easy to spin up UI using Python code. So I do all of my sort of uh hobby projects on streamlit. Uh and in terms of the exact tasks that I ran, right? So I split it into two sets of tasks that agent has to perform. The first set I'm calling it the tier one task which is atomic retrieval. So it'll be simple questions like hey how many companies are there in the database or uh yeah how many companies belong to the enterprise tier or list all the active products right straightforward single entity kind of questions. Uh then uh you have your tier 2 task which are relational discovery which will require uh you know you to join one table with other and then figure out what the answer is. Yeah. And [clears throat] then uh after running uh the experiments uh capturing uh all of that uh uh all of the results I'm persisting the results so that I can come back and revisit also the entire conversation with the agent you know I'm logging it so that I can analyze exactly where a lot of the tokens are getting consumed all of that. [snorts] So the key thing I'm I'm trying to identify right how do I determine whether graphql or a rest api is better these are the metrics that I'm using. You can use your own you know depending on what is important for you but for us what is the first and foremost uh important thing is accuracy right uh because here uh you you are not in control of what the agent is doing necessarily you can give some promps and uh guidance as English in English language but it's not necessarily that the agent might do exactly what you're asking to do so accuracy is a key factor and I couldn't figure out a very automated way of measuring accuracy so each time the API spity manually looking at the answer querying against my database and trying to uh you know calculate the accuracy. Uh speed of the outcome was uh pretty simple to calculate. I log the number of tool called round trips. Meaning if I ask a question uh something like okay for this product how many active subscribers are there? It might uh the agent might have to first get the list uh the product database then it'll have to hit the subscription database then another API call to you know hit like the usage database sorry table and get the counts so each tool call is going to add to the time right so the tool call round trips I was counting and then the final the most important metric for agentic use cases you know when you make business decision these days is the operational cost right uh and that comes in the form of form of tokens consumed so for each task what is the total token consumed both by the rest API version as well as the graphq endpoint that was also being logged so I'll just uh you know we got guidance that uh there's no Wi-Fi here you know you have to pay pay extra money if you want to use Wi-Fi so what what I did is last night I just recorded uh the application working so you can see what it looks like u so this is a landing page so these are the tasks that I mentioned right I also calculated the answers and stored it so that I can I can easily reference. So this is where you run the experiment. On the left hand side you have all the questions and you can uh run do like a batch job of running the experiment meaning you can run all the tier one questions for instance in one go. You can also choose whether you want to run the experiment for both graphql or rest api or just for one of them. The reason I built all of this is you know at times I was getting wrong results so I'll need to go back and run a specific test as opposed to running the full set. So it uh calls both the APIs uh tells you how many tokens were used, what the answer was and capsules all of that, right? So and then yeah there's a results dashboard where you can uh go in and view the final uh results and you know draw your conclusions. So this is what the setup look like. Um and sorry. Yeah. So the key question, right? So REST versus GraphQL, who won again? I'm going to ask again. Any any questions now that I showed you what uh AI showed? Any changes in answers or are you still sticking to the same answers? >> Okay. So unfortunately, like most things in software, the answer is it depends, right? Yeah. So there there's you know it's frustrating when we ask our architects hey you know should we do this or that they're like oh well it depends you know you can never get a clear answer and the an for this experiment also that's the conclusion that we came to. [snorts] So architecturally I couldn't honestly find that this protocol or this architecture was fundamentally better than the other one. Right? It really depends on the kind of task that you're trying to complete the question and also the implementation of your tool design and uh your API implementation. So just to share some uh numbers, this might blow some some people's mind, but when I first built the original app and asked a simple question like how many companies are in the system, GraphQL for instance did two calls and 35,000 tokens. Rest API did that in one call and,77 tokens and graphql also got the answer wrong by the way. And the reason for that was you know it did an introspection first. Uh so that itself blew up the token size. uh and then the there there was no functionality for tool count against the companies collection. So it just did it just listed all the ids of companies and it just counted that right? So there were 50 companies but the page nation returned only 30. So GraphQL said okay there are only 30 rows right so those are things that I then realized and then improved in my graphql setup to get the right answer and bring the countdown. Now similarly uh another question that I asked which products does you know bridewave technologies currently subscribe to graphql only,981 tokens rest took four calls and you know 30,000 tokens and to come up with the answer. Uh here if you see introspection did not have to happen necessarily the reason was in the tool design or definition my data model is pretty small right so I just told it that okay these are the collections that I have and these are the columns in the collection. So you didn't really need to introspect to figure out right. So you have all of those kind of mechanisms available to uh you know fine-tune your uh agentic solution. So at a high level sort of the conclusion that I could draw was okay you know the the winner of this war debate it really flips with a uh with the question that you're asking the agent and the key things that determine you know which gives a better performance is the kind of question that you ask and also your uh tool definition design. So I'll just share some more numbers. So [clears throat] um I I would what I would keep doing again and again was run the tier wise uh experiment meaning I had those 15 questions for atomic retrieval. I would run that against both REST API and GraphQL uh and make only minimal modifications here and there to improve the answers. So what I could see was uh atomic retrieval uh rest surprisingly did worse than graphql is because uh remember I said that I gave information about the collections already in the graphql design. So we didn't have to do introspection at all. That means graphql could straight straight away just ask uh I mean write the query uh and it knew which collection it needed to ask and which was a field it needed to get right. uh but then accuracy again you know uh rest seemed to be fairing better [clears throat] and similarly when it come to relational discovery which is where I I expected graphql to consume less tokens for some reason rest was consuming rest less tokens but one interesting thing to note here is the tool call count right uh rest on an average took around 10 round trips and that number is high because there was this one task which took I think around 30 round trips to get to the final answer but on an average it took around four to five round trips. Now this roundtrip concept is uh kind of important in agentic uh sort of solutions and I'll I'll come to that but uh these are numbers that I could get and the key thing to take away is don't take these numbers as the absolute truth right it's very dependent on the experimentation setup you have on the APIs that you have so [clears throat] these numbers won't hold good in our actual product APIs either because the APIs that I've used for the experiment were very simple APIs the APIs that I have I mean my colleague can that test for it. These are like massive APIs. For instance, when you want to retrieve a booking, right, in booking.com, you would see there is lot of information. There's the actual reservation information, there's a hotel information, there's cancellation policy, there's that. So, just when you if you just wanted to know the cancellation policy, right? In a rest API, you're getting all of these extra things. Whereas if you maybe broke it down into different uh you know sort of APIs or had like a filter parameter where you could tell what is the data that you want you could optimize the response output right and get different results. So all of these results you know it's very context dependent. It depends on which are the APIs you're using what is your tool design uh and what are the questions that you're asking. So again you know which architecture REST GraphQL you know it depends. Uh so these are the three I would say key parameters that'll depend on uh one is of course the question that you're asking the agent. The other is your actual API catalog. What are the APIs that are available? What I mean by that is if if you were uh uh implementing a truly restful sort of uh hardcore strict rest design uh what would you do? You would have resources and sub resources etc. uh everything will be res uh resource oriented right in a realistic production case you always end up creating sort of convenience APIs let's call it for lack of a better word so you might create APIs that might do a specific function or might be combining two three resources together just to make it easier for the uh consumer right so that that's what I mean by API catalog do you have those kind of convenience functions wherein an agent can directly get to an answer rather than having to navigate through the resource hierarchy So all of those kind of uh design [clears throat] decisions would affect the performance of your agent. So I mean you have come to this talk you're looking for an answer. I couldn't give one except the standard answer. It depends you know. So what should you do next right? So if you are in a position as an architect or someone who needs to make this decision and give a recommendation back to your board uh what I would recommend is first before trying to you know figure out whether you should invest in rest or graphql etc. First figure out uh what are the agents that you want to build and what are the tasks that that your agent has to perform. Okay. Then if you already have an existing uh API sort of portfolio or offering benchmark the performance of those APIs without changing anything, right? Uh and when you benchmark what you want to prioritize at least according to me is uh accuracy of how well they get you the results uh that or perform the task that they're supposed to do and also token consumption. Then as you do that benchmarking, you have to find the specific bottlenecks or issues. So for instance, if you're retrieving a booking, you're realizing that oh, I just wanted to find out uh what date my booking is on and it's consuming 100,000 tokens. That's an issue, right? That's operational cost every time a guest is going to retrieve a booking. So all of those you list uh list down. And the next step is before redoing a whole architecture and uh imple moving to another protocol what you want to do is uh you have to figure out are there ways you can optimize uh for to address that specific issue right. So I'll just talk about some examples of uh optimization solutions for high token usage. I have not run experiments to really show you data. So this is a bit theoretical right now. So the easiest thing that you can do the lowhanging fruit is your tool definition. Right? So tool definition is essentially uh kind of like open API structure it looks like uh where you're telling okay this is what the API does these are the request parameters. So you can find ways to compress the tool definition. How can you do that? An example is uh let's say I have an API where cruise name is a search parameter right now in your tool definition typically there'll be a uh string for the name of the field and there'll be a description. How about you just get rid of the description completely make the name of the attribute as cruise name AI can understand I mean LLMs can understand that right so you don't need to waste uh tokens on description saying hey this attribute holds the cruise name this is where you will pass the name of the cruise like just having the parameter name as cruise name is enough for LLM to understand that so that's what I mean by uh to sort of you know uh tool definition compression finding ways to optimize your uh tool design length The other is uh response data compression. [clears throat] Okay, so this roundtrip thing that I kept talking about, right? That is what contributes the most to token consumption in agentic use case. The reason for that is let's say you ask a question first and LLM decides that oh to find the answer for this I need to make a tool. It gives you a response. Now your total context window is the sum of the question that you asked and this response. Now you would have written some code to uh take that response from uh from the LLM which tells you which tool or API to call. Then you call the API get that response and feed that back to the LLM. So now your context window has become three sort of three conversation blocks. Then LLM processes that response and gives a response back. Right? It has become five. So now imagine uh to get to the final answer two three such tool calls are required. So your context window is continuously increasing. Right? So that roundtrip is the primary thing uh that you want to uh try and uh uh sort of reduce. So part of that is reducing the response data itself. So uh I I don't know if you have seen this on LinkedIn but there was uh a lot of conversation about how you can replace JSON responses with either YAML or you know people came up with a term called tune token optimized object notation. So YAML the uh sorry moving from JSON to YAML the advantage is you get rid of brackets and you know uh inference doesn't have to process those brackets unnecessarily tune the uh idea was for tabular data even in YAML you're repeating the header every time right so instead you just write the header once and have just the rows repeating so these are some of the optimization techniques you have for response data and then another one is response schema control going back to the booking retrieval uh use case that I said if I could mention in my request return only the cancellation policy right or return only the property details that way I can control the retrieve booking uh response. uh this is uh this slightly more advanced wherein tool definition instead of giving it as part of the context you store it in a uh as a vector embedding right so it kind of becomes like rag for tools uh and this you can do for both REST or GraphQL uh and the final frontier uh and this is what a lot of the uh you know advanced teams are working on is for tool calling instead of having uh your uh LLMs you know do the orchestrate the tool calling or sorry your code orchestrate the tool calling why don't you get your agent to write code that does the tool calling in a sequence so what I mean by that is you ask a question that requires five APIs to be called in sequence uh what you do is uh your LLM will write a code that will call those five APIs in sequence and run it in a code execution environment so you're essentially eliminating the need for uh the multiple round trips right in just one round trip you're writing a program and that is executing in in the environment and getting the result. And if you still want to go one step further, if you have deep pockets, you know, you can fine-tune LLM, feed all your API definition into the LLM and then have code invocation environments. Uh I don't think anyone does that. Okay, so that kind of wraps it up. But I'll give a bonus takeaway as well. So benchmarking in this space is very very very context dependent, right? So uh don't go by what I say or what others say in terms of which is better. uh at the end of the day it's your APIs they operate in very specific ways. So you have to run these experiments yourself. So the recommendation that I have is you have to build a benchmarking framework where you can easily plug in your tool definitions and function calls and then do the evaluation. And one more recommendation is u there are a lot of tools available out there that takes your open API spec and gives you a recommendation in terms of how ready they are for agent use cases. Uh that that that's a good start but it's not enough. you have to evaluate it uh during runtime performance also right because that's the only way you know how much tokens are getting consumed uh and uh if you're getting the right answers all right on time any questions yeah okay so the first one uh regarding uh discovery yes you're absolutely right right it's it's about which tool should I call uh that is where most of the context I mean tokens get consumed definitely for gra well for both graphql and API now uh see regarding the memory piece. Uh I I I've talking about where you know the context is being stored in sort of a persistent me memory for a a conversation and uh how that can get reused. Uh >> there are multiple ways in your files even session. >> Yeah. But but that's still going as part of the uh context, right? Even if you're storing it in uh as MD. Uh so >> I think it depends on how you define your own memory because people use multiple ways right they'll either store it in their own markdown files they'll probably have it in some vector database they might have anything but the agents don't really need to evaluate the tool or the response again and again. So let's say for example if I want to know how many uh you know companies are there or how many bookings are there the query might get saved and the next time that I want to ask the same question I don't need to do any of this >> okay so got it got it got it yeah so so you're not talking about the tool definition being persisted because that that is you know getting saved somewhere and that's being passed but the actual query and the results uh yeah uh so that see I mean I I I don't really have an answer because at least in our case the question storing that response wouldn't really makes sense, right? Because each guest they have their own uh sort of information that is pertaining to them that they're asking and we wouldn't really want to persist that data also cuz that data changes as well, right? Someone made a booking if we try to persist that memory in the agents this thing but in the transactional data the data changes it becomes stale etc. So that's a lot of uh overhead management that we have right >> no it's not actually about the response uh like akin to this is claude skills >> right >> right you have your tool definition but you also have skills which tells you how to use those tools as well >> right >> and today we don't write skills anymore because as we continue to use claude claude remembers this is how I used the tool last time you don't even have to tell me anymore right >> so I think that's where I'm getting at but I I kind of understand where >> so so the third point dynamic discovery covers uh you know all sorry I'm getting assigned times up but but I that's exactly the frontier people are trying to solve right how do you compress that tool definition this thing so dynamic discovery of tool definitions right like storing it as a vector embedding so you know rag for tools that that's one way you know the memory thing could be another way so those are potential optimization techniques