OSLC/ldp-service

Refactor ldp-service to expose reusable LDP functions in addition to express middleware functions

Opened this issue · 1 comments

An app or services such as oslc-service that uses ldp-service could:

  1. Delegate whatever it can to ldp-service, especially the CRUD resource operations
  2. Access storage services directly to implement some things such as Query Capability that are not part of LDP
  3. Combine the two by having ldp-service refactor the implementations of its CRUD methods into reusable functions that it calls to implement its own express middleware, but that could also be called by other services like oslc-service that need similar capability, but have to make additional response modifications. The ldp-service middleware subApp methods would simply call the correspond functions, then do res.sent to complete the result.

There can be many ldp-service instantiations on different storage services used by the same oslc-server. Since oslc-service also depends on storage services (for resource preview, attachments, OSLC 2.0 discovery resources, OSLC query, selective properties), then it is oslc-service that will instantiate the storage services for a particular route, providing that implementation to the ldp-service it uses.

Might do this incrementally and as needed while implementing oslc-service. This will minimize the exposed API.