Hi, on bug 12590 [1] we started a discussion on the current /svc API. Petter proposed extending the /svc/bib capabilities (which is great) but I noticed the current API does not respect the usual meaning of HTTP verbs for REST (specifically the meaning of POST). So I have a question: who is using the API and how difficult would be to adapt to using PUT instead of POST? Any thoughts? -- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ✆ +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
Hi, Changing the API would be quite simple. But not making it "retro-compatible" could be a nightmare to some installs. In our case, we "published" the addresses as call-backs. Correcting those in the remote systems _could_ be a drag, way more than the usual rebase/upgrade/fix involving code. Just a thought. Blou On 07/21/2014 03:19 PM, Tomas Cohen Arazi wrote:
Hi, on bug 12590 [1] we started a discussion on the current /svc API. Petter proposed extending the /svc/bib capabilities (which is great) but I noticed the current API does not respect the usual meaning of HTTP verbs for REST (specifically the meaning of POST).
So I have a question: who is using the API and how difficult would be to adapt to using PUT instead of POST?
Any thoughts?
-- Tomás Cohen Arazi Prosecretaría de Informática Universidad Nacional de Córdoba ? +54 351 5353750 ext 13168 GPG: B76C 6E7C 2D80 551A C765 E225 0A27 2EA1 B2F3 C15F
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Philippe Blouin, Responsable du développement informatique Tél. : (888) 604-2627 philippe.blouin@inLibro.com <mailto:philippe.blouin@inLibro.com> inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com>
* Philippe Blouin (philippe.blouin@inlibro.com) wrote:
Hi, Changing the API would be quite simple. But not making it "retro-compatible" could be a nightmare to some installs. In our case, we "published" the addresses as call-backs. Correcting those in the remote systems could be a drag, way more than the usual rebase/upgrade/fix involving code.
Just a thought.
Hi All I think we you want to do something like this (change a published and in use API) then we should version it. So that the current in use version can be version one, we make a new version 2 of the API people can transition to it. At some point in the future (maybe) we get rid of version 1 Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
On Mon, Jul 21, 2014 at 7:46 PM, Chris Cormack <chrisc@catalyst.net.nz> wrote:
* Philippe Blouin (philippe.blouin@inlibro.com) wrote:
Hi, <snipped>
I think we you want to do something like this (change a published and in use API) then we should version it.
So that the current in use version can be version one, we make a new version 2 of the API people can transition to it. At some point in the future (maybe) we get rid of version 1
+1 Sounds reasonable. -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org
participants (4)
-
Chris Cormack -
Indranil Das Gupta -
Philippe Blouin -
Tomas Cohen Arazi