Implement Resource PHP Service

[ruebot]

This is a stub ticket for implementing the Resource PHP Service. We'll flesh it out more.

[DiegoPino]

Update

https://github.com/DiegoPino/islandora/tree/example-service
Get resource is working fine.

Depends on some minor fixes on Chullo at
https://github.com/DiegoPino/chullo/tree/api

Basic (Manual testing)

1. Download/clone
2. Modify composer.json to match your local location of the previously referred Chullo
3. Modify src/index.php to match your triplestore and fedora4 URLs starting at line 32

$app['fedora'] =  $app->share(function() {
    return Chullo::create('http://localhost:8080/rest');
});

$app['triplestore'] = $app->share(function() {
  return TriplestoreClient::create('http://localhost:9999/bigdata/sparql');
});

1. run $ composer update
2. run $ php -S localhost:8282 -t src src/index.php this will use the php embed web server to test
3. Assuming you already have some containers in fedora (with uuid) you can test the working route
   with a call like this
4. $ curl http://localhost:8282/islandora/resource/7ef68f6f-72ab-4708-b0f4-8ec1f07cd580 -v
   in case you have a child resource (lets say an image binary at /OBJ) you can issue this call
5. $ curl http://localhost:8282/islandora/resource/7ef68f6f-72ab-4708-b0f4-8ec1f07cd580/OBJ -v

Also accepts this query arguments: tx=transactionid and metadata=true
Will fail if tx given and not a valid transactionid (404)
Will get fcr:metadata for any resource (e.g binary) if metadata=true

Note: if you don't have a CLAW vagrant environment working you can use(only testing)

• https://wiki.duraspace.org/display/FEDORA40/Quick+Start (download and run fcrepo-webapp-4.4.0-jetty-console.jar)
• Download standalone blazegraph https://www.blazegraph.com/download/ and run it using the described method (please lower the java memory!)
• Create a new resource in Fedora4 using the rest api (or page),
• Since you won't have an indexer running, issue an insert data command to blaze graph to be able to test (you can use the same rdf response from fedora4 for a resource + nfo:uuid property to match using the web admin at http://localhost:9999/bigdata/#update)

@todo

• Rest of the resource routes (POST/PATCH/etc). Basically i have to resolve an issue with Fedora rewriting the triples based on the host header, which in our case, since we are a middle service, depends on where we are running our silex service. This means that, e.g, our returned location in case of a POST (creating a resource) will have the host and port of silex in the resource path which is bad. Same for any other operation. We are fetching the resource path from the triple store matching nfo:uuid. That one will always be a static one(inserted on resource creation) so trouble can occur when matching that returned resource path with fedora's rest point for that resource.
  • Options are to match the host header to where fedora is running, this way, at least we would get a constant base uri, others are more complex (like living with this)
• Clean UP, bring to coding standards
• Make URL configurations external (not sure, do we wan't to keep service as slim as possible?)
• Write Unit Tests

[ruebot]

tagging @daniel-dgi

[ruebot]

Resolved with 1742149