--- title: Should I Use Rest or GraphQL APIs for My Mobile App? description: REST vs GraphQL for mobile apps explained. Discover how each handles data, where each fits best, and what to ask before you commit. image: https://weareaffective.com/hubfs/learning-centre-images/should-i-use-rest-or-graphql-apis-for-my-mobile-app.webp --- [Skip to content](https://weareaffective.com/learning-centre/should-i-use-rest-or-graphql-apis-for-my-mobile-app#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Should I Use Rest or GraphQL APIs for My Mobile App? Table of Contents The question comes up early in almost every mobile build we work on, and it usually arrives framed as a purely technical one: REST or GraphQL? Developers have strong opinions, articles take sides, and the choice can feel like it carries enormous weight before a single line of code is written. The reality is more grounded than the debate suggests. > The right API choice is the one that fits your data, your users, and your connectivity reality. Both are ways of asking a server for data and receiving a response. The difference lies in how precisely you can specify what you want, how many requests you need to make, and how much data travels back across the network. Get those things right for your product, and the choice becomes obvious. Get them wrong, and you pay for it later in [performance problems, rework, or a product that cannot scale](https://weareaffective.com/learning-centre/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app) the way you intended. We have worked through this decision across products ranging from a performance coaching survey tool to a memory-sharing proof of concept to a buying and selling platform for bottles of alcohol. Each one taught us something different about when the pattern matters and when the real constraint is somewhere else entirely. This article sets out what we have learned. There is no universal answer, but there is a clear process for reaching the right one for your product. ## What REST and GraphQL Actually Are REST stands for Representational State Transfer. It is an architectural style, not a protocol, and it has been the dominant approach to building APIs since the early 2000s. A REST API organises data into resources, each with its own URL endpoint. You make a request to a specific endpoint and receive whatever that endpoint is set up to return. The structure of the response is decided by the server, and it stays the same regardless of what the client actually needs. GraphQL is a query language developed by Meta and released publicly in 2015. Rather than hitting multiple fixed endpoints, you send a single request to one endpoint and describe exactly which fields you want back. The server returns precisely that shape of data, no more and no less. The structure of the response is driven by the client, not the server. According to [Postman's 2025 State of the API Report](https://www.postman.com/state-of-api/2025/), REST is used by 93% of developers, and GraphQL by 33%, which tells you something about maturity and familiarity. REST has decades of tooling, documentation, and developer confidence behind it. GraphQL is growing steadily, and the gap in adoption reflects how long it takes for any pattern to become second nature across an industry, not that one is inherently better than the other. ## How REST Handles Data Requests In a REST API, each type of data lives at its own endpoint. If you are building a travel app and you need a user's profile, their recent bookings, and their saved destinations, those are typically three separate requests to three separate URLs. The server returns a full response from each one, and your app assembles the data it needs from what it receives. #### Fixed response shapes The response shape from a REST endpoint is fixed. If the endpoint returns a user object with 40 fields, your app receives all 40 fields whether it asked for 5 or 40. You can filter on the client side once the data arrives, but the bandwidth has already been used. This is fine when the response is lean and the endpoint is well designed. It becomes a problem when endpoints were built for a web app and a mobile screen needs a much smaller slice of the same data. #### Caching and predictability One genuine advantage REST has is HTTP caching. Because each resource has its own URL, standard caching infrastructure works naturally with it. Responses can be cached at the network level without any special configuration, which can reduce server load and improve response times considerably. For products where data does not change frequently and read performance matters, this is a real benefit that GraphQL requires more deliberate effort to replicate. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## How GraphQL Handles Data Requests GraphQL changes the dynamic between client and server. Instead of the server defining what comes back, the client sends a query describing exactly the fields it needs, and the server resolves only those fields. A single GraphQL request can retrieve data that would otherwise require several REST calls, and the response contains exactly what was asked for, nothing else. On the memory-sharing proof-of-concept project we worked on, we needed to integrate a music catalogue search so users could attach audio clips to their memories. When we evaluated third-party APIs, the quality and design of the API exposed by each service was as much a factor as any feature. We switched from Spotify to Deezer partly because Deezer's API was more robust and designed for the way we intended to use it. Using an official API in the way its provider intends simplifies both the architecture and the compliance burden, and that principle applies equally to whether you are building your own GraphQL layer or consuming a third party's. > GraphQL lets the client drive the response shape, which removes a whole category of data waste on mobile. The tradeoff is complexity. Setting up a GraphQL server, defining a schema, and writing resolvers takes more upfront work than exposing a set of REST endpoints. For a proof of concept or an MVP where speed of build matters, that overhead is real and worth factoring into the decision before committing to the pattern. Write out the exact data your most complex screen needs before choosing an API pattern. If it maps to one or two simple endpoints, REST will serve you well. If it spans five different resource types, that screen alone is an argument for GraphQL. ## The Real Difference: Over-fetching, Under-fetching, and Round Trips These three concepts are where the practical difference between REST and GraphQL actually lives. Over-fetching happens when a REST endpoint returns more data than the client needs. Under-fetching happens when a single endpoint does not return enough, so the client has to make additional requests to fill the gap. Round trips are the number of separate network requests needed to assemble a complete view. On mobile, all three of these have a real cost. Network latency on a phone is not the same as on a wired connection. A request that takes 80ms on a desktop in a reliable environment might take 400ms on a mobile network in a weak signal area. If assembling one screen requires four round trips, those delays stack. Google's data shows that [53% of mobile visits are abandoned if loading takes longer than 3 seconds](https://blog.google/products/admanager/increase-speed-of-your-mobile-site-wi/), and even accounting for the fact that figure applies to web rather than native apps, the underlying pattern of user impatience holds. GraphQL's single-endpoint, client-specified approach addresses over-fetching and reduces round trips naturally. On a product with a complex data model and many interconnected resource types, the bandwidth savings are meaningful. [API7](https://api7.ai/blog/graphql-vs-rest-api-comparison-2025) suggests GraphQL can reduce payload sizes by 30-50% in bandwidth-constrained environments like mobile, though that figure is asserted without a cited methodology, so treat it as directionally useful rather than exact. The principle behind it is sound. ## When Your Data Needs Are Simple and REST Is the Right Call If your mobile app has a small number of distinct resource types that map cleanly to individual screens, REST is almost certainly the right choice. A booking confirmation screen, a user profile page, and a search results list each pulling from one or two endpoints is exactly the use case REST was designed for. The additional complexity of GraphQL would cost you time in setup without giving you anything back. REST is also the right call when your team's existing knowledge sits firmly there. An engineering team that knows REST deeply will move faster and make fewer mistakes than one learning GraphQL mid-build. The pattern that fits your data is only one part of the decision. The [pattern your team can execute confidently](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) is the other part, and it carries at least as much weight. If your app has fewer than ten distinct data resource types and the data relationships between them are shallow, reach for REST by default. Introduce GraphQL when you have a specific problem it solves, not because it is more technically interesting. #### When caching matters more than flexibility Caching is one of REST's genuine structural advantages. If your app serves content that changes infrequently, like a catalogue, a destination guide, or editorial content, REST's HTTP caching will reduce latency and server load without any custom configuration. GraphQL can be cached, but it requires deliberate tooling and additional decisions. For read-heavy apps with stable data, REST's caching model is worth protecting. ## When Your Data Needs Are Complex and GraphQL Earns Its Place GraphQL comes into its own when your data model is interconnected and your screens need to draw from several resource types at once. A social fitness app that needs a user's profile, their recent activity, their connections' activity, and nearby events for a single home screen would otherwise require multiple REST calls. With GraphQL, that becomes one request with a precisely shaped response. On the fitness social network product we worked on, we were solving a location-sharing problem where the data a user received needed to be carefully controlled depending on their trust relationship with another user. The sequencing of what data was disclosed and when was central to the design. That kind of [conditional, relationship-dependent data retrieval benefits](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) from the flexibility GraphQL gives the client to request exactly the right fields at the right moment in the user journey. #### When your API serves multiple clients If your backend serves a mobile app, a web app, and potentially a third-party integration, GraphQL's flexibility across clients is a strong argument. Each client can request only the fields it needs, so the mobile app does not receive the same heavy payload as the web app. REST can handle this with versioning or multiple purpose-built endpoints, but those approaches accumulate technical complexity over time. A single GraphQL schema that all clients query differently is often cleaner to maintain at scale. ## What Happens When You Skip a Proper API Layer Altogether Some products reach a point in the build where a traditional API layer is either too costly to implement or not possible given the existing codebase. This is a situation we have encountered directly, and it is worth being clear about the consequences. On a buying and selling platform for bottles of alcohol, we had already started building the mobile product when we discovered we could not implement the planned API layer. The client's existing web application had been built by another developer in a way that made it too complex to expose cleanly via an API. We ended up having to embed web elements from the existing site directly into the mobile product instead. The final solution was not as scalable or robust as we would have liked, and that was a restriction we were limited to by decisions made before we were involved. On the performance coaching survey app, we made a deliberate early decision to skip a traditional API for the MVP and use Firebase's real-time database directly as the backend. Each survey created by a presenter generated a record in Firebase, and audience members accessed their own unique response record via keys embedded in the QR code URL. This allowed real-time response logging with tight security, restricting users to reading and writing only their own record, and it kept the build lean and appropriate for a proof of concept. The biggest technical challenge on that project was locking down Firebase security rules without the protection of a dedicated API layer. We had to scrutinise every security rule carefully to ensure neither the app nor the web response page could be exploited, since there was no API acting as a controlled intermediary between the client and the database. Skipping the API layer is sometimes the right call for an MVP. It just shifts the security burden, and that burden needs to be taken seriously. ## How Connectivity Constraints Should Shape Your API Choice Mobile users are not always on fast, reliable connections. A product that performs well in a London office may behave badly in a rural area, an airport terminal, or anywhere signal is inconsistent. This is a design constraint that belongs in the API decision, and it is one that gets overlooked when the team is building and testing on a strong Wi-Fi connection throughout. On a travel product aimed at younger backpackers visiting off-grid locations, unreliable connectivity was a core design constraint. We rethought the architecture around four questions: [what information could be stored offline](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), what had to remain online, how to queue offline actions and replay them once reconnected, and how to minimise the data sent between the app and the server to make the most of any available bandwidth. Anything that could be baked into the product was, and all other content was kept as lightweight as possible. The result was a product that could function offline where feasible and made efficient use of limited or intermittent connectivity. GraphQL's ability to request only the fields you need is a real advantage in this context. Smaller payloads mean faster responses on slow connections and less data consumed by users on metered plans. If your product serves users in areas with poor connectivity, or users who are likely to be on limited data allowances, the payload efficiency GraphQL offers is a practical benefit worth building toward. Test your app on throttled network conditions during development, not just before launch. Set Chrome or your testing tool to simulate a slow 3G connection and watch which screens struggle. Those are the screens where payload size and round trip count matter most. ## Why the API You Integrate With Matters as Much as the Pattern You Choose Most mobile apps do not only talk to their own backend. They integrate with third-party services for payments, media, mapping, authentication, and more. The quality of those external APIs shapes what you can build, sometimes more than your own architectural decisions do. On the memory-sharing proof-of-concept project, we originally planned to integrate with Spotify for short audio clips. Spotify lacked a robust API for clips at the time, and users would have needed a Spotify account, which eroded the user experience. We switched to Deezer, which had a robust API, supported clips, and did not require users to be logged in. This meant users could search a catalogue larger than Spotify's and attach clips directly within the app. A further benefit was that when users wanted to hear a full track, there was an upsell path to a Deezer subscription, enabling affiliate referral revenue as a secondary income stream alongside the product itself. The lesson from that project was that [working with an official API in the way its provider intends](https://weareaffective.com/learning-centre/what-happens-to-your-ip-when-developers-leave-your-project) simplifies both the architecture and the compliance burden. Trying to work around a weak or unsuitable API creates technical debt that compounds through the build. Before committing to a third-party integration, check whether the service does what you need and whether its API does what you need in the way you intend to use it. Those are different questions, and the second one is the one that matters. ## The Cost of Getting This Decision Wrong Mid-Build Switching API architecture mid-build is expensive. It is not just a matter of changing a few endpoints. The data shapes your UI is built around, the error handling your team has written, the caching assumptions in your state management, and the [security model you have put in place](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design) all depend on the API pattern you chose at the start. Unwinding those decisions after several weeks of development costs time and money that could have been spent building. On the wellness genetics product we worked on, we were brought in to improve the emotional layer of a product that had been built in a functional way that did not match the brand feel. When we handed our designs to the development team, a third-party designer in between created something that looked very luxurious, but the development team struggled to understand how to implement it on top of their existing codebase. There was considerable back and forth to get it right. That experience illustrates a pattern we see consistently: applying a new interaction layer on top of existing architecture that was not designed for it is difficult and needs careful management. The same applies to API architecture. The earlier the decision gets made, and the more thoroughly it is stress-tested against the actual data needs of the product, the less likely it is to become a problem mid-build. [API design is not a decision to leave](https://weareaffective.com/app-architecture-design-we-are-affective) until the backend developer starts work. It belongs in the product planning phase, alongside the screen designs and the user flows. ## Questions to Ask Before You Commit to Either Approach The decision does not need to be complicated. A small set of honest questions about your product will usually point to the right answer without requiring a technical deep-dive. 1. How many distinct data resource types does your product need, and how are they related to one another? 2. How many separate API calls would your most complex screen require under a REST model? 3. What connectivity conditions will your users actually be in, and how sensitive is the experience to payload size and latency? 4. Does your API need to serve multiple clients, such as a mobile app and a web app, with different data needs? 5. What is your team's existing familiarity with each approach, and how much time do you have to build before you need to ship? 6. If you are integrating a third-party service, does its API support the specific functionality you need in the way you intend to use it? Answering those questions honestly will narrow the field quickly. A product with simple data needs, a REST-familiar team, and a tight timeline should reach for REST without hesitation. A product with a rich, interconnected data model, multiple client types, and mobile-first performance requirements has a strong case for GraphQL. Most products sit somewhere between those poles, and the questions above are how you work out which side you are closer to. There is also a third possibility: that neither pattern applies cleanly because the constraints come from the existing codebase you are integrating with, as we found on the alcohol trading platform. In that case, the question is less about REST versus GraphQL and more about what the existing system can actually expose, and whether that is enough to build the product properly. ## Conclusion REST and GraphQL are both good solutions to the same underlying problem: getting data from a server to a mobile app efficiently and reliably. The difference between them is one of fit. REST is simple, well understood, and works cleanly for products with straightforward data needs. GraphQL is more expressive, reduces wasted data transfer, and scales better across complex data models and multiple client types. What we have found across the products we have worked on is that the API pattern is often less consequential than the quality of the APIs being integrated with, the security model built around the data layer, and how early in the process the data architecture decisions get made. The alcohol trading platform taught us what it costs to have those decisions made badly before you arrive. The performance coaching survey app taught us that skipping a formal API layer entirely can work for an MVP if the security implications are taken seriously from the start. The memory-sharing proof of concept taught us that the right third-party API can change the architecture for the better in ways that go well beyond the technical. Choose the pattern that fits your data, your users, your team, and your timeline. Then treat the APIs you integrate with as a design decision in their own right, not an afterthought. If you are unsure where to start, [let's talk about your mobile app](https://weareaffective.com/get-started). ## Frequently Asked Questions What is the core difference between REST and GraphQL? REST organises data into fixed endpoints, each returning a set response shape regardless of what the client actually needs. GraphQL uses a single endpoint where the client describes exactly which fields it wants, and the server returns precisely that data. Which API approach is more widely used in the industry? According to Postman's 2025 State of the API Report, REST is used by 93% of developers compared to 33% for GraphQL. This reflects REST's decades of tooling and developer familiarity rather than any inherent superiority over GraphQL. What is over-fetching and why does it matter for mobile apps? Over-fetching happens when a REST endpoint returns more data than the client actually needs, for example sending 40 fields when the app only requires 5. For mobile apps this is a real concern, as unnecessary data consumes bandwidth and can slow performance, particularly on weaker connections. Does REST have any advantages over GraphQL? Yes, one genuine advantage of REST is HTTP caching, which is well established and straightforward to implement. REST also benefits from a much larger pool of developer familiarity, documentation, and tooling built up over decades. Is GraphQL always the better choice for mobile apps? Not necessarily. The right choice depends on your data structure, your users, and your connectivity reality. GraphQL offers precision and flexibility, but REST can be entirely appropriate when endpoints are well designed and response payloads are lean. What happens if I choose the wrong API approach early in a project? Choosing poorly can lead to performance problems, significant rework, and a product that struggles to scale as intended. Getting the data-fetching pattern wrong is a costly mistake to unpick once the app is built and in use. Can real-world mobile products help inform which approach to choose? Absolutely. Working across varied products, from performance coaching tools to buying and selling platforms, reveals that the right choice is shaped by the specific data needs and constraints of each product. Understanding those constraints clearly is the most reliable way to reach a sound decision. Is there a universal rule for choosing between REST and GraphQL? There is no single universal answer that applies to every product. However, there is a clear process for reaching the right decision, one that centres on understanding your data, your users, and the network conditions your app will operate in. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.