Maybe find a better name for /site/?

[felixarntz]

I'm a bit confused by the name /site/ for that endpoint, since when we talk about sites in WordPress, we usually mean sites of a network (multisite). This will especially become confusing once we get multisite-specific endpoints in (/sites/<id>/ and /networks/<id>/).

A first alternative idea would be /site-options/ or /site-settings/. However I already got a response on Slack that /site-options/ wouldn't be perfect either since there is a database table of that name that denotes network options (yeah, we don't use the site-options terminology there, but still not optimal).

An alternative to finding a new name could be to provide parity with what a specific /sites/<id>/ response could look like later and include the options as an addition.

For example:
Let's say we have a multisite where http://example.com is the main site and there is another site called http://subsite.example.com with site ID 2. When we access http://example.com/wp-json/wp/v2/sites/2, we would get basic data for that site, similar with what a WP_Site object currently contains. To then access more specific details on that site, we would need to call http://subsite.example.com/wp-json/wp/v2/site/. However the latter should also include everything that the MS endpoint includes (like ID, domain, path and network ID), but then additionally include all the settings for the site.

I'm not completely convinced of either solution, but I think we should think about this.

[jeremyfelt]

I'm a bit confused by the name /site/ for that endpoint, since when we talk about sites in WordPress, we usually mean sites of a network (multisite).

I started off agreeing with you, but as I typed this up started to change my opinion a bit. 😄

Here are the endpoints that I think we have to consider:

• Retrieve data about the current site. This exists on single site installs and for each site in a multisite install.
• Retrieve data about a site on the network from a central location. This exists on the main site of a network and may even exist on single sites (as a network of 1) for consistency.

My first reaction is that it should look something like this:

• Current site, single site install - mysite.com/wp-json/wp/v2/data/
• Current site, subdomain install - subdomain.wp.org/wp-json/wp/v2/data/
• Site on network, single site install - mysite.com/wp-json/wp/v2/sites/1/
• Site on network, multisite install - wp.org/wp-json/wp/v2/sites/{#}/

This means an extra endpoint exists on single site installs that may not be so useful, but it's consistent and explicit. This would also account for the impact of converting a single site to multisite and working with existing URLs.

I don't know if data is the right word here. options seems to be misleading, meta doesn't seem right. We need a word for "data, likely options, but possibly other stuff about this site" and site may work.

Though, when retrieving this data for a site via the central site, it may result in something like wp.org/wp-json/wp/v2/sites/45/site/ for consistency.

I'm not sure if I've cleared my thoughts up by typing that out, but there you go.

[danielbachhuber]

What about mysite.com/wp-json/wp/v2/settings/? The options we'll be exposing are predominately settings — other option data would be included in other controllers.

[jeremyfelt]

Hmm, I like how that looks.

This could become wp.org/wp-json/wp/v2/sites/45/settings/ when requested from a central endpoint and that still flows/makes sense.

[felixarntz]

settings sounds like a good solution to me as well.

@jeremyfelt Do we need to have this endpoint available as a "sub endpoint" of wp/v2/sites/<id>? If it has the same data, having wp/v2/settings on the specific site should be sufficient. Otherwise we could easily start assuming the same of other site-specific endpoints.

[jeremyfelt]

I guess wp-json/wp/v2/sites/45/ would help direct you to that site's /settings/ endpoint, so that's probably sufficient. I was thinking about looping through a collection of sites, but using a central URL isn't much different from the individual URLs if you have to make a new request anyway.

[joehoyle]

Cool, I think we should go with /settings in that case.