- Start Date: (fill me in with today's date, YYYY-MM-DD)
- RFC PR: (leave this empty)
- WordPress Trac Ticket: (leave this empty)
One paragraph explanation of the feature.
Why are we doing this? What use cases does it support? What is the expected outcome?
This is the bulk of the RFC. Explain the design in enough detail for somebody familiar with the API to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here.
What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing API patterns, or as a wholly new one?
Would the acceptance of this proposal mean the REST API reference must be re-organized or altered? Does it change how the REST API is taught to new users at any level?
How should this feature be introduced and taught to existing REST API users?
How should the outcome of this proposal be communicated in both the WordPress release notes, and the relevant release's developer field guide?
Why should we not do this?
Consider the impact on end-users, API consumer developers, WordPress core developers, user complexity, and interaction with other proposals.
There are tradeoffs to choosing any path, please attempt to identify them here.
What other designs have been considered? What is the impact of not doing this?
This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
Optional, but suggested for first drafts. What parts of the design are still TBD?
All text, code, and other contributions related to this proposal are licensed under the GNU General Public License, v2 or later.