4
Backend
REST vs GraphQL for a public API consumed by mobile and partners
Simplicity ↔ Flexibility
Context
Pick the API style for our first public partner API.
Our mobile apps over-fetch heavily from a REST API designed for the web. We're also launching a partner API. One camp wants GraphQL for both; another wants REST for partners and a BFF for mobile.
Concerns about GraphQL: HTTP caching, rate limiting by query cost, partner familiarity, N+1 in resolvers.
Concerns about REST: endpoint sprawl, versioning, mobile over-fetching.
What has worked for teams who expose APIs to external developers?
Constraints
- Clients
- iOS, Android, 40 partners
- Team
- 6 engineers
RESTvsGraphQL
Community verdict
REST 57%GraphQL 43%
7 engineers · 4 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
REST
GraphQL
Flexibility →
Trade-offs
Dimensions
RESTGraphQLout of 5
- Simplicity
- 5REST scores 5 of 52GraphQL scores 2 of 5
- Flexibility
- 3REST scores 3 of 55GraphQL scores 5 of 5
- Caching
- 5REST scores 5 of 5
Community discussion
4 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentFor a public API, GraphQL's flexibility is also your attack surface: deeply nested queries, expensive resolvers, introspection leaking your schema. You need query cost limits and persisted queries before you open it to partners.
Mobile is where GraphQL shines though. One round trip per screen, typed codegen for Swift/Kotlin, and the schema becomes the contract between teams.
Which suggests the answer is "both": REST for partners, GraphQL (or a BFF) for your own clients. Different consumers, different contracts.
For external partners: REST + OpenAPI, every time. Partners want curl examples, predictable rate limits and CDN caching. GraphQL query-cost limiting is a project in itself.