Fix 148 add DOIP interface / add support for operation handling

[Pfeil]

NOTE: In this branch, we implement DOIP, while at the same time experimenting with specialized handling of FAIR DOs which represent operations. It will allow to enhance the listOperation from the DOIP specificaton in a non-trivial manner. The goal is to also list operations which are not supported by the Typed PID Maker directly. Instead it offers all compatible operations it encountered.

This branch is based on #125. At some point, this branch may be used to test DOIP and the new features / adjustment coming in #125. If you like to test DOIP in Typed PID Maker, use this branch, as long as it has not been merged.

• Implement generic DOIP over HTTP structure
• Implement service.listOperations
• Implement fairdo.listOperations
  • add possibility to extract supported type/location information and to store it into the database
    • + elasticsearch
  • write sanity tests for retrieving this information from the database (and implement retrieval)
    • + elasticsearch
  • allow extracting this information via DOIP (over http)
• write some documentation somewhere (maybe just in this issue) so it can already be tested while going on

---

• write tests as far as possible
• I need some details about how exactly the compatibility of an Operation with an Operation should be done, so I can support all cases. (will be integrated in tasks below, done)
• support this types content (which has changes in the meanwhile): https://dtr-test.pidconsortium.net/#objects/21.T11148/2694e4a7a5a00d44e62b
• if multiple instance of this type are available, assume "and" or "or" (awaiting response)
• we do not need to look for intermediate objects here
• The LIST functionality may be interesting for the REST interface also: Implement it. When doing so, consider refactoring the code for better reuse. One idea would be to integrate it into the TypingService interface/implementation.

---

All other functionality is already available via REST, but for consistency, let's also implement the other operations.

Note: Consider refactoring the code in the REST interface for better reuse in other interface modules when implementing these steps.

• Implement service.hello?
• Implement service.create
• Implement service.retrieve (incl. validate? notice possible changes in Fix 114 Unclear/non-standard response for post api/v1/pit/pid #125)
• Implement service.search
• Implement fairdo.update
• Implement fairdo.delete (tombstone)
• Implement fairdo.validate (notice possible changes in Fix 114 Unclear/non-standard response for post api/v1/pit/pid #125)

---

• merge master branch and make sure everything is consistent.
• merge into master branch or version-specific dev branch, if desired.

[Pfeil]

Summary of the current state:

• new endpoint at http://domain:port/doip
• Documented in swagger, but documentation does currently not explain DOIP itself
• only OP_LIST implemented so far (see tasks)
• Not yet well-tested
• I tried to mimic the Cordra implementation. Take it as a manual so far and give feedback if something unexpected happens. Thanks! https://www.cordra.org/documentation/api/doip-api-for-http-clients.html

What does it do?

• As before, the Typed PID Maker still remembers PIDs it has seen before (in a local database).
• In addition to PID and dates, it now stores information if the DO is supporting specific "digitalObjectTypes" or "locations".
• If a DOIP request is coming in with the target being a PID and operation "OP_LIST", it extracts the types for the PID (not yet the location!) and checks if it knows DOs which claim to support this type and returns their PIDs (as well as implemented basic operations).
• Note: you can NOT call/execute these operations on the Typed PID Maker.
• To call OP_LIST on the Typed PID Maker, use "self" as a PID. But this is currently pretty useless, as most basic operations are yet to be implemented.

[Pfeil]

Spec notes:

• attribute to specify supported attributes: https://dtr-test.pidconsortium.net/#objects/21.T11148/2694e4a7a5a00d44e62b
  • may be an array (assume "or" or "and" relation?)
• No intermediate objects (as it is now), use profile inheritance instead

---

Update: I should properly read the new definition in the draft paper and point them out here!