Documentation: How do we create resources based on JSON-LD?

Created on 2 Nov 2016  路  12Comments  路  Source: Islandora/documentation

Options discussed so far:

  • Single endpoint that somehow knows what entities/bundles need to be created per rdf:type
  • Endpoint per entity/bundle type to accept POST requests, and deermining which one to use is handled elsewhere (middleware)

There's pros and cons, and perhaps other options we haven't thought of yet.

drupal help wanted question

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.

All 12 comments

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):

  • Providing the entity type as either phoney uri or string in the rdf is off the table. I say phoney because config entites don't even have a canonical route, so you can't dereference them.
  • Providing a magical UI that does every conceivable use case of a mapping seems like a dangerous hole of never ending work.
  • 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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Natkeeran picture Natkeeran  路  3Comments

dannylamb picture dannylamb  路  3Comments

akuckartz picture akuckartz  路  3Comments

acoburn picture acoburn  路  5Comments

ruebot picture ruebot  路  4Comments