Given that the API will be used for more than just WordPress data objects, I thought it would be good to discuss how we would implement Options Endpoints and then if all goes well, have a go an implementing it. This is something we'd need in say, supporting the WP-Admin via the API. Option ID seems like something we'd want to remove too.

Abstraction

I'm not currently sure how much abstraction we would want to provide for options. I might not be realistic to get a schema driven interface for options (but it would be cool), as the underlying core api is so loose and lenient. It would seem likely that we would want to support all the core options in some more meaning full way however. For example, take an option that has a date stored in format x, we'd presumably want standard date formats across the API and would therefore perhaps transforms these things. We'd only be able to do that on inbuilt options as we'd need to define it.

Types

An option value can be of arbitrary type, which means we can't do much to document and enforce types. The type of a single option can change, say from a string to an int. It would be nice to support all the inbuilt options in with validation etc, but this would require a pretty hefty array of hardcoded schema for options that doesn't currently exist in core. For example, do we allow updating siteurl to true?

Autoloading is something that would be nice to hide away, but not sure if there is valid use cases for exposing it.

Permissions

It seems all options are managed under the manage_options capability - though I'm not sure if there are meta caps on that, doesn't seem so. However, core allows modification of the required capability on a per-subpage basis via option_page_capability_{$option_page}.

Routes

I considered including the option group name or something in the route, but I think that's probably not a good idea now. It seems that just one at /wp-json/options/$option_name would be enough.

GET     /wp-json/options/siteurl
DELETE  /wp-json/options/siteurl
POST    /wp-json/options/siteurl

Object Schema

Based of information we can get, I think we'd need more information in an object that just the value it's self as the object.

{
    name: "siteurl",
    value: mixed,
    autoload: bool
}

Alternatively, we could just have the value as the object it's self, though that exposing issues with arrays etc being the direct response.

Schemas

The options may not initially seem like they are schema based, however a bunch of the stuff proposed in #759 would be pretty cool - especially around defining enums etc. With options that are arrays/objects etc, we could use that schema to markup the full object in the option value too. wp-admin/options.php really sucks because it has no inference of the data types etc of the options. It would be pretty cool if we could get all the goodness proposed in #759 for options (if said path is chosen).

The most simple hack here is to wrap get/update/delete_option, technically, that would work - but that's no an API! I think we can do a lot better than that. It may require a bunch of hardcoding for core options, and providing hooks etc for custom options, but I think it can be done.