Once [[ https://phabricator.wikimedia.org/T206010 | questions about the external interface have been answered ]], we'll need to plan the remainder of the implementation, including the use of technologies, and operational semantics.
## Some random notes
### Integrating w/ Mediawiki
We should be able to make use of [[ https://doc.wikimedia.org/mediawiki-core/master/php/classRESTBagOStuff.html | RESTBagOStuff ]] on the MediaWiki side. It uses PHP's [[ https://secure.php.net/manual/en/function.serialize.php | serialize() ]] and [[ https://secure.php.net/manual/en/function.unserialize.php | unserialize() ]] for the body of `PUT` and the response of `GET` respectively, which isn't ideal (JSON would be better), but it seems that it was [[ https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/293554 | created for this purpose ]], and so perhaps we can make a case for changing it.
If it is not possible to make backward-incompatible changes to RESTBagOStuff, we could always provide compatibility using `(Content-Type|Accept): text/plain`.
### Replication semantics
Based on the requirements for session storage, we should be able to assume in all cases that //get// and //set// use `ConsistencyLevel.LOCAL_QUORUM` and //delete// uses `ConsistencyLevel.EACH_QUORUM`. However, the service itself will be a very straightforward key-value storage implementation, likely applicable for many future use-cases, not all of which will necessarily be satisfied by these semantics. In the interest of finding balance between future-proofing and YAGNI, we could make the consistency level configurable on a per resource basis. For example, something like:
If this failed to provide enough flexibility for some future use-case, it would be straightforward to extend the API, in a backward compatible way, to accept a per-operation consistency parameter.