REST API Chat Summary – October 4

Below is the summary for the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) meeting on Thursday, October 4 (Slack Transcript).

As announced previously, @danielbachhuber is stepping up to coordinate work on REST API improvements for 5.0 / GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. Daniel has prepared a running list of Gutenberg-related API tickets in this post, which we used as an agenda for the meeting.

Gutenberg-Related Ticketticket Created for both bug reports and feature development on the bug tracker. Scrub

Blocked Tickets

  • #44862, communicating edit lock via the REST API: @timothyblynjacobs has volunteered to work on a solution. Prior discussion of this functionality dates back to REST API issue 2225.
  •  Gutenberg#8449, TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. box does not respect user’s language (coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ticket #44758: REST API does not respect user localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English.), depends on #41305 for a robust solution. I have posted separately calling for review on the proposed patch for #41305.
  • #43998, permitting unbounded requests when requesting all authors/categories/etc for use e.g. in dropdowns: this should eventually be solved with UIUI User interface/UXUX User experience improvements such as @adamsilverstein‘s PR #7385 but that may be infeasible for 5.0. An alternative to permitting unbounded requests would be to modify the frontend data layer to (invisibly to the consuming component) recursively iterate over paginated data and return a merged response object, yielding the same final client-side response without risking memory errors on the backend, but I have not had bandwidth to propose this. If you’re interested, contact me in SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at The issue is shelved for now.
  • #43887, exposing Gutenberg data version in APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. responses: what constitutes a data version depends on the final merged form of Gutenberg so this is deferred for now and will be revisited later in the 5.0 cycle.

“Next” Tickets

  • #45016, exposing theme_supports data via the REST API: @desrosj has volunteered to pick this up to implement a bare-bones theme controller exposing the information Gutenberg needs. Gutenberg#6539 may need to be addressed in tandem.
  • Gutenberg#3315, page says “post updated” when it’s a page: we discussed adding a labels property to the /wp/v2/types response objects, but a PR is open on the Gutenberg repo and current discussion is directed there.
  • Gutenberg#8757, support default title and content when creating new posts: @mnelson4 has proposed a PR.
  • #43316, supporting autosaves: we would like to land this in the next couple days, if anybody wants to work on a final patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..
  • All participants were encouraged to review other tickets from the list in Daniel’s post, and chime in on any tickets which have a patch and are noted as ready-to-commit, to ensure any outstanding issues are surfaced before patches land.

Other Issues

  • #39953 is provisionally good to land, but has not been merged yet pending review of other milestoned REST API tickets and a call from @pento or other 5.0 shot-caller on whether it should be included.

If you have bandwidth to assist with REST API development over the coming weeks, please reach out to myself and @danielbachhuber and we will work with you to find a good issue for you to help with! If you are interested in a ticket listed above and your name is not the name of the person I mentioned who is working on it, that’s OK! Reach out to them and put your heads together, and we’ll be able to land these all the faster. Any and all assistance is welcome, and if you don’t have time to prepare a patch yourself, we always need help testing and reviewing existing patches.

Agenda for October 11 Chat

The next REST API meeting will be this Thursday, October 11, 2018 at 17:00 UTC in the #core-restapi slack channel. We will be checking in on how the tickets above have progressed, and reviewing any new priority issues. See you there!