Implement rest api layer over db

[jfroelich]

Notes derived from #800 comment:

I actually liked the simplicity of this description of REST: https://restfulapi.net/resource-naming/ because it went straight at some the questions I was trying to answer, and pretty much confirmed my thinking.

As a part of switching to rest layer, moving to a data-only api, where everything outside of the rest api is just data passed in and out, and everything inside of the api is kind of like now. this is kind of the strong boundary concept i want from a service oriented architecture

But see this article: https://www.infoq.com/news/2015/02/service-boundaries-healthcare. Services share contract and schema, not class or type. Other than pure communication between them, services do not share access to resources, including databases, because this might introduce dependencies between them. Services own their data. A service has to have both some sort of functionality and some data. If it does not have data, then it is just a function. If all that it does is performing CRUD operations on data, then it is database. A database should not be made a service just to provide basic operations on data through RESTful calls because these introduce supplementary layers that are not needed. SQL is good enough.

Similar issue (regarding my decision to store favicon data in an entirely separate database): Dahan does not see any problem for services keeping their data in the same shared database as long as each service has its own schema.

[jfroelich]

This is waiting on #654. Once I merge things into resources store, it will be more straightforward to implement as rest api and avoid wasted work.

[jfroelich]

How do messages get broadcasted? If we are trying to pretend rest api was from a different server, none of those messages would come back in (maybe as push?). so what has to happen? the rest client generates the messages?

[jfroelich]

Interesting comment from FIDL documentation: https://fuchsia.googlesource.com/fuchsia/+/master/docs/development/languages/fidl/tutorial/README.md

Single request, multiple response

The multiple response case can be used in a “subscription” model. The client's message “primes” the server, for example, requesting notification whenever something happens.

The client then goes about its business.

Some time later, the server notices that the condition that the client is interested in has happened, and thus sends the client a message. From a client / server point of view, this message is a “reply”, with the client receiving it asynchronously to its request.

There‘s no reason why the server couldn’t send another message when another event of interest occurs; this is the “multiple response” version of the model. Note that the second (and subsequent) responses are sent without the client sending any additional messages.

[jfroelich]

So maybe what I could do, is on the client side of the rest api, have some utility function like subscribe (completely unrelated to existing op). Here subscribe function basically does this:

function subscribe() {
  return new BroadcastChannel('reader');
}

The user of the client can then attach the listener to the channel, close the channel (unsubscribe), etc. So it ends up working kind of like now.

[jfroelich]

To share connection across separate requests (e.g. mimic Http Keep Alive), I can do a few things. One, I can use a request/response model. So, build a request object. Then, reusing the connection is simply a matter of setting the connection property of the request (e.g. as a key in a 'headers' map, or as an explicit property).