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.kivila...@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
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Reply via email to