Open joepio opened 3 years ago
Maybe the /commit
endpoint should also be an.. Endpoint? It's a bit different from the other examples:
/commit
endpoint works with POST
methods, not GET
.body
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.
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...
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 #61 #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:
So next up is creating these Endpoints for existing handler on the server.