[Koha-devel] Mini roadmap for the API

Arthur Suzuki arthur.suzuki at biblibre.com
Tue Oct 8 02:31:36 CEST 2019


Hi Tomas,
I'd say both parameters shall be sent in the body of the request (just like when sending a new password using the API).
In that case you could have a parameter called "depth" and a parameter called "relations" with a json array of keys?
This way the url called doesn't change much and even a quite big relations list can be provided.
HAL looks great by the way, i just discover this!

Le 7 octobre 2019 21:32:04 GMT+02:00, Tomas Cohen Arazi <tomascohen at gmail.com> a écrit :
>Hi, with the HAL introduction in mind I plan to (at least) provide a
>sample
>implementation of the following:
>
>- Add a 'to_api' method to Koha::Object and Koha::Objects that can be
>overloaded if needed (trivial, WIP 23770)
>- Pick a sample endpoint (probably /cities) and make sure the
>implementation keeps the current behaviour (trivial, besides the boring
>tests)
>- Move the existing controllers into using this (trivial)
>- Implement in some sample class, to be determined, ->to_api_hal. And
>make
>the endpoint that uses it, Accept: application/hal+json and return this
>new
>data structure. So if JSON is requested, the current behaviour is kept.
>Otherwise, the HAL representation will be returned.
>
>Things to think about and which we will be able to play with:
>- How to determine the depth of the embedding? (HAL has that ability)
>- Should we specify which FK to follow and embed on the query? how
>would
>that query look like?
>
>Thanks for your time :-D
>
>-- 
>Tomás Cohen Arazi
>Theke Solutions (http://theke.io)
>✆ +54 9351 3513384
>GPG: B2F3C15F

Arthur Suzuki
Développeur Support chez BibLibre
+33 6 37 94 13 53
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20191008/8aad3fcf/attachment-0001.html>


More information about the Koha-devel mailing list