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 56%GraphQL 44%
9 engineers · 3 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
3 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentMobile 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.