Summary: | Add REST API route to update biblio metadata | ||
---|---|---|---|
Product: | Koha | Reporter: | Julian Maurice <julian.maurice> |
Component: | REST API | Assignee: | Julian Maurice <julian.maurice> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | bibliothek, m.de.rooy, paul.derscheid, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31801 | ||
Change sponsored?: | --- | Patch complexity: | Small patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | |||
Bug Blocks: | 17371 | ||
Attachments: |
Bug 30799: Add REST API route to update biblio metadata
Bug 30799: Add REST API route to update biblio metadata |
Description
Julian Maurice
2022-05-18 12:17:18 UTC
Created attachment 135102 [details] [review] Bug 30799: Add REST API route to update biblio metadata Example: PUT /api/v1/biblios/{biblio_id}/metadata <record> ... </record> Calling this endpoint will replace the current MARC record with the one given in the request body, by calling C4::Biblio::ModBiblio Test plan: 1. Try requesting this endpoint with your favorite API tool 2. Run `prove t/db_dependent/api/v1/biblios/metadata/put.t` Created attachment 135197 [details] [review] Bug 30799: Add REST API route to update biblio metadata Example: PUT /api/v1/biblios/{biblio_id}/metadata <record> ... </record> Calling this endpoint will replace the current MARC record with the one given in the request body, by calling C4::Biblio::ModBiblio Test plan: 1. Try requesting this endpoint with your favorite API tool 2. Run `prove t/db_dependent/api/v1/biblios/metadata/put.t` Signed-off-by: Paul Derscheid <paul.derscheid@lmscloud.de> --- Works as advertised. Passes provided test. Current status: Signed Off Good to see this one. Just a dumb question: Would it be useful to allow for partial MARC record updates too instead of replacing the complete MARC record? Suppose I just want to add one new field somewhere, and not want to risk overwriting the complete MARC record somehow with an older version or so? (In reply to Marcel de Rooy from comment #3) > Good to see this one. > Just a dumb question: Would it be useful to allow for partial MARC record > updates too instead of replacing the complete MARC record? > Suppose I just want to add one new field somewhere, and not want to risk > overwriting the complete MARC record somehow with an older version or so? That'd be routes that implement the overlay stuff. We should have a call to talk about possible endpoints design. I still have doubts on thie report. It seems that we are skipping quite some validations that the interface normally does for us via the frameworks etc. Can we get more consensus about that first ? (In reply to Marcel de Rooy from comment #5) > I still have doubts on thie report. > It seems that we are skipping quite some validations that the interface > normally does for us via the frameworks etc. Do you mean things like mandatory fields ? Does this validation happen outside of the editor, for instance when using the import tool ? (In reply to Julian Maurice from comment #6) > (In reply to Marcel de Rooy from comment #5) > > I still have doubts on thie report. > > It seems that we are skipping quite some validations that the interface > > normally does for us via the frameworks etc. > > Do you mean things like mandatory fields ? > Does this validation happen outside of the editor, for instance when using > the import tool ? Ha good point. Import will skip them too. When we import and overwrite, we are doing the same.. (In reply to Marcel de Rooy from comment #3) > Good to see this one. > Just a dumb question: Would it be useful to allow for partial MARC record > updates too instead of replacing the complete MARC record? > Suppose I just want to add one new field somewhere, and not want to risk > overwriting the complete MARC record somehow with an older version or so? If we wanted to add a PATCH route, we need to think of it in terms of the MARC overlay rules. Not because it needs to use that particularly (it could) but because we need a way to express the possible behaviors as we did on that dev. In that case there's a form for setting rules, for a PATCH route we would either need to add some payload representing the same, or just pointing to some overlay rule. This would be really interesting, but certainly a bigger dev and another report. I think a 'full' overwrite if described as such would be a good first step. If we could make it follow overlay rules, maybe by adding a new filter 'REST API' that would be great. *** This bug has been marked as a duplicate of bug 31801 *** |