[Koha-devel] REST API and new defaults (Zeno Tajoli)

Olli-Antti Hypernova olli-antti.kivilahti at hypernova.fi
Fri Oct 6 19:05:47 CEST 2023


Yes this is important, and how the merging should be actually done is 
something the GUI needs to deal with.

When the PUT/POST -request is done, we already need to know how the 
merger is performed.

When you POST to /biblios/123/merges, you would semantically be creating 
a new instance of a bibio-merge -object, which is actually a pretty good 
idea.
This would allow us the undo merge-operations, or basically any type of 
biblio modification operation.


https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT
BTW: Since when has PUT been labeled as idempotent?
https://datatracker.ietf.org/doc/html/rfc2616
well since 1999 it seems :)
"However, it is possible that a sequence of several requests is non-
    idempotent, even if all of the methods executed in that sequence are
    idempotent."

A bit like can a GET request have a body or formData arguments...


On 6.10.2023 19.21, Tomas Cohen Arazi wrote:
>
>
> El vie, 6 oct 2023 a las 11:03, Olli-Antti Hypernova 
> (<olli-antti.kivilahti at hypernova.fi>) escribió:
>
>     Good idea. Anything to disband the "SmartUI"-antipattern is good
>     for me.
>
>
>     We should add a new endpoint following established nomenclature.
>
>     eg. PUT /biblios/123/merge/456   (PUT as it is modifying existing
>     records)
>
>
> POST /biblios/123/merges
> {
>     "biblio_id": 456,
>     "rules": ?
> }
>
> -- 
> Tomás Cohen Arazi
> Theke Solutions (https://theke.io)
> ✆ +54 9351 3513384
> GPG: B2F3C15F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20231006/056fbc72/attachment.htm>


More information about the Koha-devel mailing list