[wp-trac] [WordPress Trac] #45252: Reconsider the `context` argument in REST API calls

[WordPress Trac]

#45252: Reconsider the `context` argument in REST API calls
-------------------------+-----------------------------
 Reporter:  youknowriad  |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:
 Severity:  normal       |   Keywords:
  Focuses:  rest-api     |
-------------------------+-----------------------------
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45252>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform