Re: [Koha-devel] REST API and new defaults (Zeno Tajoli)
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) regarding b) We should separate Mojololicious from Plack, because Plack prevents the use of websockets and more advanced Mojolicious features. It is not such a biggie to implement. We can control two processes from the same koha-plack -script, so the CLI management API doesnt need to change either. On 6.10.2023 13.00, koha-devel-request@lists.koha-community.org wrote:
Message: 1 Date: Fri, 6 Oct 2023 10:01:18 +0200 From: Zeno Tajoli<ztajoli@gmail.com> To: koha-devel<koha-devel@lists.koha-community.org> Subject: [Koha-devel] REST API and new defaults Message-ID: <CACwhcG0R2BUPM+X0NSkiA4d7em2vzgyb0yuWrR-gGpx=rPOEdw@mail.gmail.com> Content-Type: text/plain; charset="UTF-8"
Hi to all, thinking about BZ 33036, the basic idea is to change a part of ../cataloguing/merge.pl to create a 'merge' verb inside Koha/REST/V1/Biblios.pm then use this new verb in a new version of ./cataloguing/merge.pl
But if we use REST inside standard scripts, I think we need to change those defaults: a)RESTBasicAuth: from 'Not enabled' to 'Enabled' b)Plack as mandatory
As I see also ERM needs those defaults
So is it a direction to take?
In .. ../cataloguing/merge.pl I insert a check on the environment.
Cheers Zeno Tajoli
El vie, 6 oct 2023 a las 11:03, Olli-Antti Hypernova (< olli-antti.kivilahti@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
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@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
Hi to all, in fact POST is the only not idempotent method, so: POST /biblios/123/merge/456 options a json with inside a full MARCXML, the result of the merge, not rules The user does the merge on FE, as is done today. If there isn't a full MARCXML the record with the id 456 is deleted now, and the record with 123 has all items, etc attached, See the test of the present patch: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=152678 Cheers Zeno Tajoli On Fri, Oct 6, 2023 at 7:06 PM Olli-Antti Hypernova <olli-antti.kivilahti@hypernova.fi> wrote:
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@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/
participants (3)
-
Olli-Antti Hypernova -
Tomas Cohen Arazi -
Zeno Tajoli