Discussion: APIs

[kintopp]

Placeholder for API discussions. Currently, on the suggestion that EM Places support the new Linked Places Gazetteer Interchange Format https://github.com/LinkedPasts/linked-places for Pelagios compatibility, not the Peripleo v1 or v2 API.

[gklyne]

My preference for programmatic access to LPIF data would to use a simple HTTP GET to a published place URL, using HTTP content negotiation to access the LPIF data format.

For example

Client requests:

C: GET /place/place-id
C: Host: example.org
C: Accept: application/vnd.linkedpasts.place+json

Server responds with something like:

S: HTTP/1.1 302 Found
S: Location: http://example.org/place/linkedpasts-place/place-id

A subsequent request to http://example.org/place/linkedpasts-place/place-id returns LPIF data. This all means that there is no "secret handshake" whereby the client has to have prior knowledge of how the server offers LPIF as opposed to (say) EMPlaces linked data format, and doesn't preempt the server's control of its URI space (cf. https://tools.ietf.org/html/rfc7320).

For this to work, there needs to be a MIME content type for the LPIF data that is distinct from other formats that a server might return; hence an issue I've raised at Linked Pasts: LinkedPasts/linked-places-format#4.

If we're generating LPIF data dumps, I believe this could be implemented using an off-the-shelf web server (e.g. Apache or Nginx) to front-end the EMPlaces server, to generate the content negotiation redirects or reverse-proxy according to the specific request received.