Make WordPress Core

Opened 6 years ago

Last modified 4 years ago

#45252 new enhancement

Reconsider the `context` argument in REST API calls

Reported by: youknowriad's profile youknowriad Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: REST API Keywords:
Focuses: rest-api Cc:


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

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.

Change History (3)

#1 @youknowriad
6 years ago

  • Component changed from General to REST API

This ticket was mentioned in Slack in #core-restapi by desrosj. View the logs.

5 years ago

This ticket was mentioned in Slack in #core-restapi by aduth. View the logs.

4 years ago

Note: See TracTickets for help on using tickets.