Opened 6 years ago
Last modified 5 years ago
#45252 new enhancement
Reconsider the `context` argument in REST API calls
Reported by: | youknowriad | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | REST API | Keywords: | |
Focuses: | rest-api | Cc: |
Description
When creating an abstraction on top of the REST API, the line is often blurry between edit
context and view
context.
This issue is made visible in https://github.com/WordPress/gutenberg/issues/11335
The data module of Gutenberg is an abstraction layer allowing the consumer (logged-in users) to fetch WordPress data organized in entities (posts, taxonomies, ...). Each entity in the abstraction layer has a well-defined "format". At the moment, this format is defined by the returned value of the REST API in the edit
context. This makes it impossible for users that don't have access to the edit
context to use the data layer because conceptually the data layer is not a layer on top of the REST API, it uses the REST API as just an implementation detail, it's a layer to retrieve WordPress data.
So while I think we should rethink if we need the context
argument entirely, I propose to do this iteratively and not change everything at the moment.
Can we consider this?
- Instead of returning 403 when users don't have access to the
edit
context, consider returning 200 but limiting the returned fields to the fields the current user has access to.
An argument for context could be to limit the size of the response or the time spent to compute all the fields, for me this is redundant with _fields
and we shouldn't mix both use-cases: Security and Performance.