Open frankiejarrett opened 8 years ago
@rmccue @danielbachhuber Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks? e.g. /network/1/site/1
Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks?
I'd think the latter. @jeremyfelt?
I think we should consider renaming the site_id property to network_id and blog_id to id (since this endpoint is already in the site scope).
Definitely. This gives us a chance to stay sane with naming.
Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks? e.g. /network/1/site/1
I thing a network endpoint makes sense. Not only for multiple networks but to manage the network level settings in a single network setup.
The site endpoint should provide its network_id
though.
Would we want to include this data too, or should there be a multisite-specific endpoint later to account for multiple networks? e.g.
/network/1/site/1
I'd have /network/{id}
and /site/{id}
completely separate, as you can reassign sites to different networks. This means we can also enhance the API with the endpoints as they're needed; i.e. only have /site/{id}
for multisite, and only have /network/{id}
for multinetwork; as @jeremyfelt mentions though, we may want to have these around all the time, specifically for stuff like sitemeta
/network options.
network_id
should just be network
; no need for the suffix if it's clear what the number means.
I'd also only offer these endpoints on the primary site (and the network endpoints only on the primary network) personally.
network_id
should just benetwork
; no need for the suffix if it's clear what the number means
I'm not sure about this. It would be clear what it means, but I would assume that a field called network
would actually contain a "sub-object" for the network. Also by using network_id
we'd have parity with the class naming.
I'd also only offer these endpoints on the primary site (and the network endpoints only on the primary network) personally.
+1, this certainly makes sense. It might be useful however to be able to find out from any site where to find the primary site.
New properties
When we are on a multisite install it would be good to expose additional properties for the
site
endpoint that can be fetched from theblogs
table viaget_blog_details()
.id
network_id
domain
path
registered
last_updated
attributes
(public, archived, spam, deleted, mature) - possibly private?upload_space_quota
- privatepost_count
- privateuser_count
- privateProperty name changes
Multisite allows you to have not only multiple sites, but multiple networks of sites. However, the traditional name for a network is
site
, and the traditional name for a site isblog
. Yay.Since we are dubbing this REST endpoint as
site
it might be confusing to use the traditionalsite_id
andblog_id
names when we are in a multisite install.I think we should consider renaming the
site_id
property tonetwork_id
andblog_id
toid
(since this endpoint is already in thesite
scope).Additionally, I think we should rename the
blog_upload_space
property toupload_space_quota
.