DiegoPino
commented
3 years ago Nice. Ok, since this is archipelago, tiny little islands where we build stuff everyday using twigs and scrap metal (@alliomeria et Al) so we are going to do things differently that the contributed D8 OAI modules in the wild (here is my plan, lurkers take note!) Ingredientes:
- First: where does the data come from? From Solr. Most configurable way of getting it in Archipelago? Via a Solr Entity Data View (special thing which we coded, provide and is quite a thing): So a
zuperfast data View! (we just need the NODE ids for that) - Second: What is passed to the Data view? Arguments o course. Each view can have varying arguments and users can be quite creative.
- Third: How do we expose this? A custom Metadata API Endpoint, a special variation of our Metadata Endpoints (yeah, not directly via the View API, that is not our way, we need more control and some cleaner stuff). This custom Metadata API Endpoints use the same idea of the Per Node ones (old good `/do/{uuid}/metadata/{metadata name}/default.{extensionforformat}), but! This kids allow a few new tricks:
You can configure Arguments that are allowed and their format (GET API Builder!):
- Arguments can affect 4 different things:
A. Can pass (map) from the API endpoint URL via GET to the View internally (e.g when calling a for a.
Set) B. Can pass(map) from the API endpoint URL via GET and modify which actual Metadata endpoint is called for each record (IIIF, MODS, etc). Also only ones matching the Primary response type of this API endpoint will be allowed to be set as options. (nice!) B. Can pass(map) from the API endpoint URL via GET and feed(injected into) the actual metadata endpoint Twig source/Metadata Display entity (as $context) for cool dynamic rendering and modification and stuff of metadata - Allow us also to generate a Wrapper (Also Twig template) Response. All that goes around the actual data.
- Caching works great on these (because caching will not be applied to the response itself (each Node) but to the actual Node rendering. So add a node and you get immediate response.
- Permissions are of course enforced and we can dynamically also also roles/assignment as we do for Form Modes (plugin
derivers, since this are config entities)
This also solves of course any issues with "Uh, Oh, I need ETDS, can someone code it?" Twig template + add to the config, map the value. Done.
@alliomeria @giancarlobi how do you feel about this?
And other uses (wait for it)
- IIIF Search API (just a wrapper, nice responses)
- OAI-ORE. Set output to JSON-LD, change the argument, done (and using all the same Solr data view as PHM)
- IIIF Collection API Set output to JSON-LD, change the argument, use a different template.
Final crazy idea (which we already discussed with Giancarlo at some moment in the past but I can not find which issue) https://apisyouwonthate.com/blog/openapi-v31-and-json-schema-2019-09
e.g of an API described via openapi
parameters:
- in: query
name: limit
schema:
type: integer
maximum: 50
examples: # Multiple examples
zero: # Distinct name
value: 0 # Example value
summary: A sample limit value # Optional description
max: # Distinct name
value: 50 # Example value
summary: A sample limit value # Optional descriptionMy crazy idea is quite simple. The configuration entity will be setup in such a way that the output of one of these will have close shape to the OpenAPI specs to define the arguments (in:query) and what they do.
That way you can even invent your own API. And done.
Good night.
dmer
patdunlavey
What?
Check another box off the Roadmap!