Move more server logic to endpoints

[joepio]

atomic-server has a couple of endpoints that provide a bunch of features:

• /tpf: triple-pattern fragments search
• /path: atomic path query resolving
• /validate: validate some ad3 graph (not sure if I want to keep this Repurpose Validate #61 Validate JSON-AD (endpoint + CLI option) #333 )

These tend to return kind of inconsistent responses. Validate only returns an HTML page, and none of them even return atomic resources consistently. For handling collections, sorting and pagination #17 and versioning #42, I've been using Extended Resources - which basically means that (some of) their values are dynamic; they are calculated at runtime. I think this would be a powerful abstraction for the plugin system #73.

So... What are Endpoints?

Let the struct speak for itself:

/// An API endpoint at some path which accepts requests and returns some Resource.
pub struct Endpoint {
  /// The part behind the server domain, e.g. '/versions' or '/collections'. Include the slash.
  pub path: String,
  /// The function that is called when the request matches the path
  pub handle: fn(subject: url::Url, store: &Db) -> AtomicResult<Resource>,
  /// The list of properties that can be passed to the Endpoint as Query parameters
  pub params: Vec<String>,
  pub description: String,
  pub shortname: String,
}

So next up is creating these Endpoints for existing handler on the server.

[joepio]

Maybe the /commit endpoint should also be an.. Endpoint? It's a bit different from the other examples:

• The /commit endpoint works with POST methods, not GET.
• It parses the body
• It does not use query parameters

So where does it fit? Is it an Endpoint? If it is, how do we describe what body is accepted? How do we describe that the user can POST to it instead of GET? Do we introduce a GetEndpoint and a PostEndpoint?

This requires some more thought.

[joepio]

Not sure about the /tpf endpoint. If I move it from server to lib, it will no longer be able to behave like most TPF endpoints do - it will not return a bunch of triples, but a Collection containing Resources. Even if the user would request turtle serialization, it would receive the Collection, and not a bunch of triples that match the pattern.

Maybe I should create a second tpf-like endpoint, and keep the older one? Maybe just have a /collection endpoint which accepts a property and a value, which already is supported by collections...