We propose to introduce a
dashboard REST 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”) https://developer.wordpress.org/rest-api/. namespace prefix, for use on endpoints specifically relating to the WordPress admin (and super admin) dashboard.
WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. currently contains two namespace prefixes:
oembed. These represent two separate APIs offered by WordPress: the general REST API which exposes structured WordPress data objects to external clients, and the OEmbed implementation.
The general design of WordPress distinguishes between the core, and the Dashboard “application” built on top of it. These two have not traditionally been formally separated, however the design and clean slate of the REST API allows us to consider these separately as we evolve the Dashboard.
With the push towards removing admin-ajax handlers in favour of new REST API endpoints, there are naturally API 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. endpoints being introduced which are not useful outside of the administrative interface. Endpoints for Dashboard Widgets, pointers, and other features are specific to the Dashboard application, and are not broadly applicable to public-facing WordPress sites or third-party applications.
Introducing a new
dashboard namespace prefix allows separating Dashboard-specific endpoints from the public WordPress REST API. This can also allow for future changes, deprecations, and new versions of the Dashboard API without requiring a version bump for the public REST API.
New endpoints for the Dashboard will live under
dashboard/, initially with the namespace
dashboard/v1 for the first version of endpoints.
Future iterations of the Dashboard that need to break API backwards compatibility can increment the version under the same namespace prefix as needed (e.g.
dashboard/v3). These new versions do not need to affect the public WordPress REST API.
This requires no code changes, as it simply designates the namespace for future use. The first endpoints to be added under this new namespace are expected to be the endpoints for Site Health (#48105) in WordPress 5.4.
How do we communicate this?
The new endpoints under the
dashboard namespace prefix will collectively be called the Dashboard REST API to distinguish them from the public WordPress REST API.
There are no user-facing changes resulting from this proposal. Likewise, there is no effect on plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, theme, or API client developers.
The difference between
dashboard needs to be communicated to core developers working on the Dashboard and related features. The announcement of this RFC on the Make/Core blog (versus network, site) will serve as an initial announcement, but evergreen documentation should be added to the Core Handbook.
A new page will be added to the REST API Handbook under the “Best Practices” section, outlining design guidelines for new endpoints added to WordPress Core. The proposed text for this page is:
Core implementations of REST API endpoints should follow some simple rules to ensure WordPress provides a consistent public data interface.
Creating New Endpoints
Where possible, core features should use existing REST API endpoints rather than adding new ones. For example, a tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) search feature should use the existing tag collection endpoint in the REST API rather than building one specifically for the feature.
When a new endpoint is required, care should be put into the design of the external API. In particular, the shape and schema of the resource, the namespace, the route (URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org), and the available actions should match existing precedent in core.
REST API endpoints intended for public use and which represent “core” features of WordPress should be under the public REST API namespace (
wp/v2). Endpoints which are only applicable for the Dashboard (e.g. Dashboard Widgets, pointers, or other UI User interface settings) should be under the Dashboard REST API namespace (
dashboard/v1). This ensures a clear distinction between APIs for general consumption and APIs built for specific UI features.
The design and implementation of the endpoint can be checked by the REST API team before committing to ensure it is consistent with the rest of the API. This helps us provide a more consistent experience for API consumers.
Introducing a new core namespace could impact third-party plugins or other code which uses the same namespace string. This represents a minor backwards compatibility break, and investigation needs to be done as to whether we’re breaking any major plugins with this change.
It could also be argued that it fragments core’s API surface to introduce an entirely new namespace. Making the distinction of which namespace to use is tough, and this might lead to features that could have general applicability existing only as part of the Dashboard API, without a public API for use by external clients.
In addition, adding a new namespace opens the question of whether more even namespaces are needed. For example, should there be a Customizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. namespace? Do other features need their own namespaces as well?
There are a few main alternatives to creating a
dashboard namespace prefix.
The first is to use the current
wp/v2 namespace for endpoints relating to administrative interfaces like Site Health. The main reason to avoid doing this is that it couples Dashboard-specific features to the public REST API. These features are rarely applicable or usable outside of the Dashboard application, especially in third-party plugin interfaces or external clients. In addition, this would also tie Dashboard API versioning to the public REST API, which could lead to the public REST API version being needlessly bumped for Dashboard-only changes.
Another alternative is to use a sub-namespace prefix of the existing
wp prefix, such as
wp/dashboard. This avoids any risk of impacting existing plugins as
wp is already known to be reserved for core. However, this breaks the current precedent of
<prefix>/v<version>, increasing the complexity of API namespacing. Given that it is unlikely that the
dashboard prefix is currently being used, the simpler option of
dashboard/v1 is preferred. This also discourages a proliferation of sub-namespaces under the
The final alternative is creating a separate namespace for each feature, such as
site-health/v1. This could have the advantage of making endpoints more discoverable, and would reduce the overall length of each endpoint’s URIs. A
dashboard prefix may also imply that its endpoints are “private” to WordPress and specific to the WordPress display context in cases where future endpoints may be useful in third-party tools. This approach has the disadvantage that plugin developers may worry that any namespace they pick could eventually be reappropriated by WordPress core.
- Should we use
dashboard/v1? To some
dashboard is unclear and meaningless, to others
admin is very specific to
dashboard is more general idea of management.
- Should we use
wp/dashboard/v1? The former could potentially clash with plugins, and is much more generic. We also need to pave the way for further namespaces that may be added to core in the future, where clashes may be more common.
Originally written by @rmccue as a WP-API Proposal.