In StepZen adding an access control rule like that would look like ⬇️ access: The exact implementation heavily depends on the specific GraphQL server technology. Though, the former only applies when fetching the film query field whereas the latter applies in any query. For example, both Query.film.* and Film.* address the same title field on the Film entity. This security model is more flexible and simultaneously more complex, as it allows the creation of multiple overlapping rules. For example, “ reading any film properties (by querying the Query.film.* fields) requires a USER role”. With GraphQL, the “natural” granularity level for access control rules is “per field”. Implementing it could look something like ⬇️ (using express.js in this example). This approach fits well to the REST model, it is straightforward to implement, and so it is commonly used. For example, “ reading the film data (by sending a GET to the /films/:id endpoint) requires a USER role”. With REST, the “natural” granularity level for access control rules is “per endpoint per action type”. Additionally, most IDEs have plugins and extensions that automatically introspect GraphQL APIs and use the extracted schema for auto-completion, inline documentation, and build-time type checking.įigure 1: using GraphiQL to explore a GraphQL API Approach to securityīoth REST and GraphQL have ways to secure access to the API, though there is no single standard for either of them. This leads to better tooling support - most GraphQL APIs allow using the same standard Graph iQL tool both as an API explorer and as a playground. With GraphQL, the schema is a required part of any API, and it can be introspected using the GraphQL API itself. Good APIs would have it, but creating it requires using separate tooling and formats like OpenAPI.
However, with REST, a schema is an optional addition, similar to API documentation. "description": "A military airship utilized by the government to access Laputa"īoth REST and GraphQL allow you to create typed API schemas. Thus, every response could have a different shape, and adding an extra property is trivial if this property is available in the GraphQL API at all.
With GraphQL, every API call requires an explicit query specifying the shape of the response. NOTE: The examples in this article use the public Studio Ghibli API (both REST and GraphQL). Adding an extra property to a response requires changes to the API backend and would affect all API consumers. With REST, the shape of a response is typically fixed for each API endpoint. Unlike REST, GraphQL places more control over the shape and content of responses in the hands of an API consumer. More flexible queries, built-in typed schema, a different approach to security, and subscriptions are the key difference points that make GraphQL powerful and more complex than REST. It solves a similar set of problems as REST but comes with a different set of trade-offs. 🎥 This article is based on our recent video where we explore the pros and cons of GraphQL versus REST Should you use GraphQL? What makes GraphQL different?
0 kommentar(er)
