OAI-PMH Support (UXPROD-993)

[MODOAIPMH-1] OAI-PMH: Define API Created: 28/Sep/18  Updated: 14/Nov/18  Resolved: 12/Oct/18

Status: Closed
Project: mod-oai-pmh
Components: None
Affects versions: None
Fix versions: 1.0.0
Parent: OAI-PMH Support

Type: Story Priority: P2
Reporter: Hkaplanian Assignee: Hkaplanian
Resolution: Done Votes: 0
Labels: sprint48
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original estimate: Not Specified

Issue links:
Relates
relates to UXPROD-350 OAI-PMH Support Closed
Sub-tasks:
Key
Summary
Type
Status
Assignee
MODOAIPMH-3 Define RAML Sub-task Closed Pavel Korolenok  
MODOAIPMH-4 Define Module/Deployment Descriptors Sub-task Closed Aliaksandr Pautau  
MODOAIPMH-5 Raml Module Builder Sub-task Closed Piotr Kalashuk  
MODOAIPMH-6 Define schemas Sub-task Closed Piotr Kalashuk  
Sprint: oai-pmh - sprint 48
Story Points: 8
Development Team: Thunderjet
Epic Link: OAI-PMH Support

 Description   

1. RAML
2. Schemas
3. RMB
4. Module Descriptor

At the end of this story we'll have a skeleton in place with stub methods



 Comments   
Comment by Craig McNally [ 05/Oct/18 ]

Craig McNally check with Vince to see if the backend module needs to follow the oai-pmh spec, or if the API can be split up into various endpoints...

Comment by Craig McNally [ 05/Oct/18 ]

I discussed with Vince and we agree it makes sense to split up the API into multiple endpoints. One thing that occurred to me was that doing so allows for fine-grained permissions, whereas using a single endpoint would only allow for all-or-nothing permissions.

The endpoints should be as RESTful as possible...

e.g. GET /oai2?verb=GetRecord on the edge should map to something like GET /record in the module.

Comment by Pavel Korolenok [ 09/Oct/18 ]

Hi Craig McNally,

I've got a couple of questions about response part of the OAI-PMH endpoints.

Edge API
The specification does not provide strict rules as to how to utilize HTTP codes. Generally (and looking at other implementations, e.g. http://export.arxiv.org/oai2?verb=nastyVerb), "200 OK" is usually utilized in all scenarios. In event of an error, the body includes the XML response containing OAI-PMH error element with OAI specific error code.

Do we want/need to follow this approach in edge API?

Back-end module API
With an intention to make the back-end endpoints as RESTful as possible, there are at least 2 ways to return errors to Edge module:

  • always return "200 OK" status code with OAI-PMH XML in the response (error element with OAI-PMH error code)
  • return different status codes for specific error cases (e.g. 400 for badResumptionToken, 404 for idDoesNotExist, etc.) with OAI-PMH XML in the response (error element with OAI-PMH error code)
    • XML body is still required here, because not all OAI codes clearly map to specific HTTP codes so that Edge can translate it.

What would be the preferable option here?

Comment by Craig McNally [ 09/Oct/18 ]

My gut feeling is that we should return applicable 4XX/5XX response codes, I'll take a look at the error codes and try to provide advice on error code -> http status code mappings... e.g.

400 for badVerb, badResumptionToken, badArgument
404 for idDoesNotExist, noRecordsMatch
422 for cannotDisseminateFormat, noMetadataFormats
501 for noSetHierarchy - should never happen in our case since we do support sets (at least the "all" set initially)

Comment by Pavel Korolenok [ 12/Oct/18 ]

Hi Hkaplanian,
the story is completed and ready for review.

Generated at Fri Feb 09 00:13:35 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.