Each of these APIs provide a "playground" like experience where you can sign in and start building/testing/executing operations within the docs page. The playground is a better DX than what you see in a Swagger UI "Try it" button because you can execute a GraphQL request that includes multiple entities. This type of request would typically require orchestrating multiple REST API calls in some code for developers.
A big benefit we've seen in the industry is being able to control the API orchestration for developers. With REST, the developers using your public API are using SDKs (provided or generated) and some code (most likely initially written/scaffolded by an Agent). For whatever use case they are building, they might need to interact with multiple of your endpoints. The code they write to do that is something you have little control over and many API teams will conduct developer interviews to come up with new endpoints that solve situations where a developer needed to call multiple endpoints. A GraphQL operation can be more representative of the intention of your user and allow them to cross endpoint boundaries. They no longer are writing code to orchestrate, just building the operation with the fields of information they need. GraphQL helps bridge those entity connections for developers without having to write code.
There are downsides for using GraphQL for a public API. Your documentation experience is typically different and in the examples I referenced, you can see they all have some "explanation" content that helps a developer understand how to make an API call. This is because GraphQL is less used than REST (33% vs 92% in Postman survey) and a new-to-GraphQL developer has to initially learn how to construct an operation in the playground. Internal developers that are familiar with REST will have to learn how to bring those capabilities to GraphQL (i.e. moving function code from routes to resolvers). It's not much different code-wise, but it's definitely a mind shift.
I also know many companies that use GraphQL for their internal usage of APIs, but provide only an external public REST API (and some of those REST APIs are just a facade over the GraphQL API). I don't think there is a wrong answer here. I personally like GraphQL because it enables an API to encapsulate a lot of business logic that is typically needed to connect entities in our domains. You of course can design REST APIs that give a similar feeling depending on your use case.
Disclaimer: I work at Apollo GraphQL as Head of DevRel
GraphQL is in public usage a lot, Postman's State of the API Report (https://www.postman.com/state-of-api/2025/#api-testing-and-t...) REST is still the largest but GraphQL is growing and at 33% in their survey. You can look at the recent GraphQL Conf (https://graphql.org/conf/2025/) and GraphQL Summit (https://summit.graphql.com/) for examples of companies running GraphQL in production today. The recordings for those conferences should be up soon.
There are some public facing GraphQL APIs that I think are great examples:
1. Braintree (https://developer.paypal.com/braintree/graphql/explorer) 2. Shopify Storefront (https://help.shopify.com/api/storefront-api) 3. Shopify Admin (https://shopify.dev/docs/api/admin-graphql) 4. Monday.com (https://monday.com/developers/v2/try-it-yourself) 5. Yelp (https://docs.developer.yelp.com/docs/graphql-intro)
Each of these APIs provide a "playground" like experience where you can sign in and start building/testing/executing operations within the docs page. The playground is a better DX than what you see in a Swagger UI "Try it" button because you can execute a GraphQL request that includes multiple entities. This type of request would typically require orchestrating multiple REST API calls in some code for developers.
A big benefit we've seen in the industry is being able to control the API orchestration for developers. With REST, the developers using your public API are using SDKs (provided or generated) and some code (most likely initially written/scaffolded by an Agent). For whatever use case they are building, they might need to interact with multiple of your endpoints. The code they write to do that is something you have little control over and many API teams will conduct developer interviews to come up with new endpoints that solve situations where a developer needed to call multiple endpoints. A GraphQL operation can be more representative of the intention of your user and allow them to cross endpoint boundaries. They no longer are writing code to orchestrate, just building the operation with the fields of information they need. GraphQL helps bridge those entity connections for developers without having to write code.
There are downsides for using GraphQL for a public API. Your documentation experience is typically different and in the examples I referenced, you can see they all have some "explanation" content that helps a developer understand how to make an API call. This is because GraphQL is less used than REST (33% vs 92% in Postman survey) and a new-to-GraphQL developer has to initially learn how to construct an operation in the playground. Internal developers that are familiar with REST will have to learn how to bring those capabilities to GraphQL (i.e. moving function code from routes to resolvers). It's not much different code-wise, but it's definitely a mind shift.
I also know many companies that use GraphQL for their internal usage of APIs, but provide only an external public REST API (and some of those REST APIs are just a facade over the GraphQL API). I don't think there is a wrong answer here. I personally like GraphQL because it enables an API to encapsulate a lot of business logic that is typically needed to connect entities in our domains. You of course can design REST APIs that give a similar feeling depending on your use case.
I hope this helps!
[dead]