It would be worth considering the following refactoring of the code, where HTTP requests are dealt with directly by the actor for the resource.
This actor should then deal with:
access control
etags
mime types etc...
return types
This would allow:
the system to be distributed for large databases with multiple servers could handle subsets of resources and redirect the requests directly to the relevant actor.
the resource actor could itself keep mini databases of acls so as to reduce the computation time needed to calculate them
the actor could work out directly if the etag is valid. Currently there is a problem because the front end has to request the meta data in one step and then check the etag. In the mean time another write could occur.
the actor could work out exactly what type of object to return, for example it could return a stream directly instead of having to serialise a graph. Note that some actors would still keep graphs in memory, eg in order to make calculations of acls easier, or to allow queries.
because the full headers could be sent to the actor, it would have a lot more information about what it should do with the request, making it much more extensible.
There may be other advantages and disadvantages to consider. So this is the space to list them.
It would be worth considering the following refactoring of the code, where HTTP requests are dealt with directly by the actor for the resource.
This actor should then deal with:
This would allow:
There may be other advantages and disadvantages to consider. So this is the space to list them.