Options discussed so far:
There's pros and cons, and perhaps other options we haven't thought of yet.
I'm inclined to stick to the single endpoint.
@ruebot yeah. Second and third thought say the same to me now. Lets stick to one then.
@DiegoPino @ruebot Agreed that it's ideal, but still scratching my head for the least terrible way to do this.
Things I don't think will work (e.g. the majority of my past few weeks):
Right now I'm looking into doing a reverse lookup on RDF mappings. E.g. the rdf:type provided in the message body makes an _exact_ match on a particular bundle's mapping. It's not ideal, but at least a non-programmer could control the rdf mapping through a config file while a UI gets sorted out.
But that's just my latest guess. Any other thoughts are appreciated.
Providing a magical UI that does every conceivable use case of a mapping seems like a dangerous hole of never ending work.
:clap:
@dannylamb can you expand on this one a little bit more?
Not providing a UI and doing it in hooks would be fine, but take the power away from the non-developer end users. If a site builder makes a bundle through the UI, you couldn't hit the rest endpoint to make a new entity until a developer implements the hook.
This means every time you make a new content type, you need a developer to implement a hook with your own custom logic to discern the content type from the provided jsonld. Otherwise the REST api won't function properly. You could do everything through Drupal forms, but could not create a new entity by posting to /islandora/object (or whatever we make the endpoint).
I guess the real question is, do we want site builders to be able to have this level of power? Or do we restrict it to only developer types. Given everything else it would take to make a new type of content in Islandora (new derivative types require new microservices, etc...) you could make an argument that this is for developers only.
Also, re: hooks vs reverse mapping lookup, it's the classic trade off between complexity and flexibility. Do we want to make it super flexible with the cost of maintenance, or accept limitations and get something easier to implement/maintain.
By hooks do you mean hooks or events, I don't know much about Drupal 8 but I'm pretty sure they want to move to events for everything.
Seriously, we should avoid hooks as much as possible.
This means every time you make a new content type, you need a developer to implement a hook with your own custom logic to discern the content type from the provided jsonld.
So that's essentially what solution packs are in 1.x, right?
do we want site builders to be able to have this level of power?
It's Drupal, and that's one of the big things right? Empowering site builder. Maybe we talk this one out a lot more on Wednesday?
What we implement ourselves will be events, but we can't avoid hooks altogether. There's too many left in core :(
I'm going to move forward on this with it being implemented as a seperate microservice, with the default impl being an attempted match through the RDF mappings. That way, people who don't care get reasonable default behaivor, and those who want more can customize.
Consensus on November 9th, CLAW Call: https://github.com/Islandora-CLAW/CLAW/wiki/November-9%2C-2016
Most helpful comment
I'm going to move forward on this with it being implemented as a seperate microservice, with the default impl being an attempted match through the RDF mappings. That way, people who don't care get reasonable default behaivor, and those who want more can customize.