There was an excellent conversation started by @guillemcordoba in another thread about URI-based addressing for entries kept in zome storage APIs. In here, @pauldaoust floated the idea of an RPC-based URI scheme, which I agreed at the time was a pragmatic and sensible way of addressing the problem.
I’ve been thinking about this a bit more and I’ve realised a protocol scheme that follows the RPC API structures is probably a bad design decision.
The reason is just that RPC was a poor choice to represent distributed addressable data in the first place. It’s too flexible. An interface that can expose any arbitrary function to the caller is not an interface that conforms to representations of stateful data.
That’s what we’re really talking about here- the need for a REpresentational State Transfer protocol on Holochain. It ties into something I tried to do early on that couldn’t be implemented: turning Holochain into a Solid pod.
The reason you can’t do this yet is that Solid follows the REST model using standard HTTP verbs, and the Holochain conductor only allows you to POST through a JSONRPC interface. This is the same limitation- Holochain doesn’t have a built-in standards-compliant model for representing data structures and means of accessing them.
So I would advocate a two-stage process for this:
- Create a “RESTful” zome trait that zomes wanting to conform to such data models can implement; and implement a URI resolver zome & lib which is compatible with these traits. This solution is actually fine and seems “Holochain native” in that it’s an app-layer implementation, and that it considers the conductor JSONRPC interface to be the “native” Holochain protocol, which it is.
- Push this functionality into core and expose standard HTTP verbs using zome trait bindings, such that RESTful HTTP APIs can be built on Holochain more easily. In effect this would allow you to skip the use of an intermediary webserver (or UI and the HOLO hosting network) in order to expose the data to the wider web in a standards-compliant way, which was a possibility we spoke of in the other thread.
Going ahead with this would mean building 3 complementary components:
- A set of
hc_zome_restful_apicrates, which provide the zome traits for use in zomes wishing to expose REST interfaces to record data and/or possible framework/implementation details -
hc_zome_rest_resolver, which can be mixed in to zomes wishing to interact with RESTfully conforming bridged zomes in order to read records from them -
@holochain/hc-restful-resolveror similar as a JS-native front-end library that can be used to resolve holochain URIs against anyhc_zome_restful_api; basically the UI-layer version ofhc_zome_rest_resolver
Would like to keep this discussion going and get more input on this framing of the problem and solution design… please ping any others you feel should be involved (:
