The Checkouts API route RFC (https://wiki.koha-community.org/wiki/Checkouts_endpoint_RFC) proposes a POST on /checkouts, which makes sense.
Created attachment 91632 [details] [review] Bug 23336: Add POST /checkouts issue endpoint This patch adds a POST /checkouts issue endpoint for creating checkouts Test plan: - Run unit tests in t/db_dependent/api/v1/checkouts.t - Make POST request to http://yourlibrary/api/v1/checkouts with request body containing at least 'patron_id' & 'barcode' properties, other possible properties are: "due_date": Checkout due date "inprocess": Boolean "ignore_reserves": Boolean "cancel_reserve": Either null, "revert" or "cancel" "issue_date": Checkout issue date "sipmode": Boolean "params": Object containing arbitrary properties that will be passed to CanBookBeRenewed and AddIssue - Observe returned data and HTTP code - 201 for checkout created - 403 for cannot be checked out (with reason in response body) - 404 for either invalid patron or barcode - 500 for something else went wrong
Created attachment 91633 [details] [review] Bug 23336: Add POST /checkouts issue endpoint This patch adds a POST /checkouts issue endpoint for creating checkouts Test plan: - Run unit tests in t/db_dependent/api/v1/checkouts.t - Make POST request to http://yourlibrary/api/v1/checkouts with request body containing at least 'patron_id' & 'barcode' properties, other possible properties are: "due_date": Checkout due date "inprocess": Boolean "ignore_reserves": Boolean "cancel_reserve": Either null, "revert" or "cancel" "issue_date": Checkout issue date "sipmode": Boolean "params": Object containing arbitrary properties that will be passed to CanBookBeRenewed and AddIssue - Observe returned data and HTTP code - 201 for checkout created - 403 for cannot be checked out (with reason in response body) - 404 for either invalid patron or barcode - 500 for something else went wrong
Created attachment 91634 [details] [review] Bug 23336: Add POST /checkouts issue endpoint This patch adds a POST /checkouts issue endpoint for creating checkouts Test plan: - Run unit tests in t/db_dependent/api/v1/checkouts.t - Make POST request to http://yourlibrary/api/v1/checkouts with request body containing at least 'patron_id' & 'barcode' properties, other possible properties are: "due_date": Checkout due date "inprocess": Boolean "ignore_reserves": Boolean "cancel_reserve": Either null, "revert" or "cancel" "issue_date": Checkout issue date "sipmode": Boolean "params": Object containing arbitrary properties that will be passed to CanBookBeRenewed and AddIssue - Observe returned data and HTTP code - 201 for checkout created - 403 for cannot be checked out (with reason in response body) - 404 for either invalid patron or barcode - 500 for something else went wrong
I'm in the process of reviewing this patch. The unit tests pass without incident. Unfortunately, I'm getting a 400 error with the message "Expected object - got null." when POSTing to the endpoint. Not sure if it's my set up or not. Once this is conquered, it would be helpful to have more information about what behavior to expect from requests with the other specified parameters. Can they introduce other response codes in certain circumstances (such as 'cancel_reserve' = 'foo'), etc.
Hi Ian, I think your first comment warrants a "Failed QA" on this one to get the attention of the developer. Also I think we need documentation on the wiki to vote on for this new part of the checkouts API. Right away I notice some things to fix: reserves for example should not be used, but hold, issue should be checkout etc. We have agreed to standardize on the English GUI language.
Hi Ian I've not been able to replicate your 400 when POSTing, it would be interesting to know if others can. This patch is a *very* thin proxy on top of calls to C4::Circulation::CanBookBeIssued and C4::Circulation::AddIssue - terminology, parameter requirements and response specifications come directly from them. Unfortunately CanBookBeIssued in particular can potentially return a wide range of responses, which are currently just proxied back to the API consumer in the "error" object. Whether any more preparation of the response prior to return is required is up for debate.
Created attachment 150947 [details] [review] Bug 23336: Unit tests This patch adds unit tests for the new checkout availability endpoint we're going to introduce in this patchset. Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150948 [details] [review] Bug 23336: Add checkout API's This patch adds API's to allow for a checkout flow using the RESTful API. We add an availability endpoint to check an items current availability status. The endpoint can be found at `/checkouts/availability` and is a GET request that requires item_id and patron_id passed as parameters. We return an availability object that includes blockers, confirms, warnings and a confirmation token to be used for checkout. We also add a corresponding checkout method to the `/checkouts` endpoint. The method accepts a POST request with checkout details including item_id , patron_id and the confirmation token in the body. Future work: We should properly migrate CanBookBeIssued into Koha::* and use that here instead of refering to C4::Circulation. Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150949 [details] [review] Bug 23336: Fix inconsistent return of AddIssue AddIssue can on occasion create a renewal instead of a fresh issue and in such a case we currently return undefined. We should be consistent and return the existing issue object for the renewal. Signed-off-by: Helen Oliver <HOliver@tavi-port.ac.uk> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
This is a complete rework based on the implementation I did for bug 30979
Created attachment 150954 [details] [review] Bug 23336: Unit tests This patch adds unit tests for the new checkout availability endpoint we're going to introduce in this patchset. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150955 [details] [review] Bug 23336: Add checkout API's This patch adds API's to allow for a checkout flow using the RESTful API. We add an availability endpoint to check an items current availability status. The endpoint can be found at `/checkouts/availability` and is a GET request that requires item_id and patron_id passed as parameters. We return an availability object that includes blockers, confirms, warnings and a confirmation token to be used for checkout. We also add a corresponding checkout method to the `/checkouts` endpoint. The method accepts a POST request with checkout details including item_id , patron_id and the confirmation token in the body. Future work: We should properly migrate CanBookBeIssued into Koha::* and use that here instead of refering to C4::Circulation. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150956 [details] [review] Bug 23336: Fix inconsistent return of AddIssue AddIssue can on occasion create a renewal instead of a fresh issue and in such a case we currently return undefined. We should be consistent and return the existing issue object for the renewal. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150960 [details] [review] Bug 23336: Unit tests This patch adds unit tests for the new checkout availability endpoint we're going to introduce in this patchset. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150961 [details] [review] Bug 23336: Add checkout API's This patch adds API's to allow for a checkout flow using the RESTful API. We add an availability endpoint to check an items current availability status. The endpoint can be found at `/checkouts/availability` and is a GET request that requires item_id and patron_id passed as parameters. We return an availability object that includes blockers, confirms, warnings and a confirmation token to be used for checkout. We also add a corresponding checkout method to the `/checkouts` endpoint. The method accepts a POST request with checkout details including item_id , patron_id and the confirmation token in the body. Future work: We should properly migrate CanBookBeIssued into Koha::* and use that here instead of refering to C4::Circulation. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Created attachment 150962 [details] [review] Bug 23336: Fix inconsistent return of AddIssue AddIssue can on occasion create a renewal instead of a fresh issue and in such a case we currently return undefined. We should be consistent and return the existing issue object for the renewal. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
*** Bug 24400 has been marked as a duplicate of this bug. ***
Going to be working on the check-in API endpoint now just in case there is already work being done on it, I really should have checked for duplicates before working on the checkout one too but oh well.
(In reply to Danyon Sewell from comment #18) > Going to be working on the check-in API endpoint now just in case there is > already work being done on it, I really should have checked for duplicates > before working on the checkout one too but oh well. Duplicates are not always easy to spot especially with different terminology used (issue/checkout etc.). I hope this fits your needs as well? And welcome, Danyon :)
I'm not aware of anyone working on a Check-in endpoint.. do you have a specification you're working from? I found checkout to be rather complex given all the cases that need to be accounted for (and not all of them are accounted or here as yet.. hence the tail of follow-up bugs) and I'm envisaging the same for Check-in.
Why are not you using Koha::Token here? Koha/Token.pm:use Mojo::JWT;
Shouldn't we also rework/reword the confirmation/errors/warnings we send to the client?
(In reply to Jonathan Druart from comment #21) > Why are not you using Koha::Token here? > > Koha/Token.pm:use Mojo::JWT; Because the work I split this out from has been in progress for months and I totally forgot the existence of Koha::Token. I can follow-up here to move to that.
(In reply to Jonathan Druart from comment #22) > Shouldn't we also rework/reword the confirmation/errors/warnings we send to > the client? Also yes.. but I wanted to continue working through modernising this in follow-up bugs.. I was under pressure to get the OPAC trusted self-checkout bug that this is at the bottom of the tree of in... and I found that doing the job properly was well and truly out of scope for the sponsor.. I intend to continue in my own time to improve things here.. perhaps we could mark the endpoint as experimental, allowing ourselves to continue the cleanup whilst still pushing this to allow the core feature to be present.
Having now looked at Koha::Token it really doesn't feel appropriate here.. we get rid of claims entirely which is what I'm relying on here.. I find it strange to drop the fundamental point of a JWT in Koha::Token.. can you explain?
(In reply to Martin Renvoize from comment #25) > Having now looked at Koha::Token it really doesn't feel appropriate here.. > we get rid of claims entirely which is what I'm relying on here.. I find it > strange to drop the fundamental point of a JWT in Koha::Token.. can you > explain? We can extend it if you think it's missing something. But IMO we should not use Mojo::JWT directly if we have our own Koha::Token that is using it.
Created attachment 151253 [details] [review] Bug 23336: (follow-up) Switch to using Koha::Token
Follow-up to use Koha::Token now added.
Created attachment 151318 [details] [review] Bug 23336: Unit tests This patch adds unit tests for the new checkout availability endpoint we're going to introduce in this patchset. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151319 [details] [review] Bug 23336: Add checkout API's This patch adds API's to allow for a checkout flow using the RESTful API. We add an availability endpoint to check an items current availability status. The endpoint can be found at `/checkouts/availability` and is a GET request that requires item_id and patron_id passed as parameters. We return an availability object that includes blockers, confirms, warnings and a confirmation token to be used for checkout. We also add a corresponding checkout method to the `/checkouts` endpoint. The method accepts a POST request with checkout details including item_id , patron_id and the confirmation token in the body. Future work: We should properly migrate CanBookBeIssued into Koha::* and use that here instead of refering to C4::Circulation. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151320 [details] [review] Bug 23336: Fix inconsistent return of AddIssue AddIssue can on occasion create a renewal instead of a fresh issue and in such a case we currently return undefined. We should be consistent and return the existing issue object for the renewal. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151321 [details] [review] Bug 23336: (follow-up) Switch to using Koha::Token Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151322 [details] [review] Bug 23336: (QA follow-up) Some minor fixes This patch deals with some QA script warnings, and also makes some changes in line with bug 33556. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
I took some time to review this and added my two cents. Things to note: - There are a couple failing tests - I expected to see a use of check_jwt (at least) in the tests - Maybe the Koha::Token use on bug 33675 might be of help (I used the session id for the token id, etc)
Created attachment 151353 [details] [review] Bug 23336: Unit tests This patch adds unit tests for the new checkout availability endpoint we're going to introduce in this patchset. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151354 [details] [review] Bug 23336: Add checkout API's This patch adds API's to allow for a checkout flow using the RESTful API. We add an availability endpoint to check an items current availability status. The endpoint can be found at `/checkouts/availability` and is a GET request that requires item_id and patron_id passed as parameters. We return an availability object that includes blockers, confirms, warnings and a confirmation token to be used for checkout. We also add a corresponding checkout method to the `/checkouts` endpoint. The method accepts a POST request with checkout details including item_id , patron_id and the confirmation token in the body. Future work: We should properly migrate CanBookBeIssued into Koha::* and use that here instead of refering to C4::Circulation. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151355 [details] [review] Bug 23336: Fix inconsistent return of AddIssue AddIssue can on occasion create a renewal instead of a fresh issue and in such a case we currently return undefined. We should be consistent and return the existing issue object for the renewal. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151356 [details] [review] Bug 23336: (follow-up) Switch to using Koha::Token Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 151357 [details] [review] Bug 23336: (QA follow-up) Minor fixes This patch deals with some QA script warnings, and also makes some changes in line with bug 33556. We also adds current user id and checkout item id into the confirmation token to improve security and fix the failing tests. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Tests are passing again, and a little more thorough.. I kept your fixes and squashed a few extra's of my own into that same patch. Back to PQA to see what you think.. at this point I'm not worried if we hit 23.05, though I'd keep this and the tree that depends on it moving if we don't hit release so it can be pushed early next cycle rather than get stuck for another few months and pushed up against the deadline of 23.11
Patch no longer applies 8-(.. (from trying to test bug 24401): git bz apply 23336 Bug 23336 - Add an API endpoint for checking an item out to a patron 151322 - Bug 23336: (QA follow-up) Some minor fixes 151353 - Bug 23336: Unit tests 151354 - Bug 23336: Add checkout API's 151355 - Bug 23336: Fix inconsistent return of AddIssue 151356 - Bug 23336: (follow-up) Switch to using Koha::Token 151357 - Bug 23336: (QA follow-up) Minor fixes Apply? [(y)es, (n)o, (i)nteractive] y Applying: Bug 23336: (QA follow-up) Some minor fixes error: sha1 information is lacking or useless (Koha/REST/V1/Checkouts.pm). error: could not build fake ancestor Patch failed at 0001 Bug 23336: (QA follow-up) Some minor fixes
Created attachment 152712 [details] [review] Bug 23336: Unit tests This patch adds unit tests for the new checkout availability endpoint we're going to introduce in this patchset. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 152713 [details] [review] Bug 23336: Add checkout API's This patch adds API's to allow for a checkout flow using the RESTful API. We add an availability endpoint to check an items current availability status. The endpoint can be found at `/checkouts/availability` and is a GET request that requires item_id and patron_id passed as parameters. We return an availability object that includes blockers, confirms, warnings and a confirmation token to be used for checkout. We also add a corresponding checkout method to the `/checkouts` endpoint. The method accepts a POST request with checkout details including item_id , patron_id and the confirmation token in the body. Future work: We should properly migrate CanBookBeIssued into Koha::* and use that here instead of refering to C4::Circulation. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 152714 [details] [review] Bug 23336: Fix inconsistent return of AddIssue AddIssue can on occasion create a renewal instead of a fresh issue and in such a case we currently return undefined. We should be consistent and return the existing issue object for the renewal. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 152715 [details] [review] Bug 23336: (follow-up) Switch to using Koha::Token Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 152716 [details] [review] Bug 23336: (QA follow-up) Minor fixes This patch deals with some QA script warnings, and also makes some changes in line with bug 33556. We also adds current user id and checkout item id into the confirmation token to improve security and fix the failing tests. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Created attachment 152938 [details] [review] Bug 23336: (QA follow-up) Minor fixes There are two leftover includes, and a couple typos in a comment and POD title. This patch fixes that. Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Pushed to master for 23.11. Nice work everyone, thanks!
Hi, this needs more work: 1) prove xt/api.t => FAIL. It seems you either need to add an exception ofr the added route or add the `additionalProperties: false` on the object definition. 2) prove t/db_dependent/Circulation.t => FAIL. 38139718f534f308e5eb846f5e26ef54c01c3376 is the first bad commit commit 38139718f534f308e5eb846f5e26ef54c01c3376 Author: Martin Renvoize <martin.renvoize@ptfs-europe.com> Date: Mon Oct 3 17:07:20 2022 +0100 Bug 23336: Fix inconsistent return of AddIssue AddIssue can on occasion create a renewal instead of a fresh issue and in such a case we currently return undefined. We should be consistent and return the existing issue object for the renewal. Signed-off-by: Silvia Meakins <smeakins@eso.org> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> C4/Circulation.pm | 1 + So probably just a matter of adjusting the tests BUT I'd like you to check the uses of AddIssue, in case there's some stray case in which it is expecting an empty string.
Created attachment 152999 [details] [review] Bug 23336: (follow-up) Fix failing test Our consistency improvement to the AddIssue return in bug 23336 highlighted a bad test assumption. The 'Reinsert the original issue' line was silently failing and as such the subsequent test lines were actually resulting in a renewal (which previous to this patchset returned an empty return that happened to match the empty return of an issue failure)
Created attachment 153000 [details] [review] Bug 23336: (follow-up) Add checkout_availability schema At some point in the patch series we lost the availability api schema. This patch restores a basic version, but we should work towards a clearer enum based schema for each of the available blockers, confirms and warnings.
C4::Circ 1536 # get actual issuing if there is one 1537 my $actualissue = $item_object->checkout; 1549 $issue = Koha::Checkouts->find( { itemnumber => $item_object->itemnumber } ); 1549 should call ->checkout as well
There are a couple of warnings t/db_dependent/api/v1/checkouts.t ...... 7/101 Argument "1672:1738:confirm1:confirm2:please" isn't numeric in numeric eq (==) at /kohadevbox/koha/Koha/Token.pm line 298. Argument "1672:1738:confirm1:confirm2" isn't numeric in numeric eq (==) at /kohadevbox/koha/Koha/Token.pm line 298. t/db_dependent/api/v1/checkouts.t ...... 100/101 Argument "1674:1739:confirm1:confirm2" isn't numeric in numeric eq (==) at /kohadevbox/koha/Koha/Token.pm line 298. Argument "1674:1739:confirm1:confirm2:please" isn't numeric in numeric eq (==) at /kohadevbox/koha/Koha/Token.pm line 298.
(In reply to Jonathan Druart from comment #52) > C4::Circ > > 1536 # get actual issuing if there is one > 1537 my $actualissue = $item_object->checkout; > > 1549 $issue = Koha::Checkouts->find( { itemnumber => > $item_object->itemnumber } ); > > 1549 should call ->checkout as well Do you think this is a blocker for the follow-ups? Or can that be moved to a separate bug for Martin to take care?
(In reply to Tomás Cohen Arazi from comment #54) > (In reply to Jonathan Druart from comment #52) > > C4::Circ > > > > 1536 # get actual issuing if there is one > > 1537 my $actualissue = $item_object->checkout; > > > > 1549 $issue = Koha::Checkouts->find( { itemnumber => > > $item_object->itemnumber } ); > > > > 1549 should call ->checkout as well > > Do you think this is a blocker for the follow-ups? Or can that be moved to a > separate bug for Martin to take care? That is not related to the follow-ups. That can be done separately, or kept as it if you consider it's ok.
Follow-ups pushed. Martin will file a separate bug for those standing issues.
(In reply to Jonathan Druart from comment #53) > There are a couple of warnings > > t/db_dependent/api/v1/checkouts.t ...... 7/101 Argument > "1672:1738:confirm1:confirm2:please" isn't numeric in numeric eq (==) at > /kohadevbox/koha/Koha/Token.pm line 298. > Argument "1672:1738:confirm1:confirm2" isn't numeric in numeric eq (==) at > /kohadevbox/koha/Koha/Token.pm line 298. > t/db_dependent/api/v1/checkouts.t ...... 100/101 Argument > "1674:1739:confirm1:confirm2" isn't numeric in numeric eq (==) at > /kohadevbox/koha/Koha/Token.pm line 298. > Argument "1674:1739:confirm1:confirm2:please" isn't numeric in numeric eq > (==) at /kohadevbox/koha/Koha/Token.pm line 298. There is something very wrong with this warning, it should not be ignored.
Created attachment 153095 [details] [review] Bug 23336: Compare strings with eq instead of == And don't ignore warnings next time ;)
Created attachment 153096 [details] [review] Bug 23336: Fix tests Not sure what we were trying to do, but apparently we only use the keys to generate the id string. How did "please" end up here?
Last 2 patches need a stamp from someone involved originally here.
See 34212 for all follow-ups (I move Jonathan's there too as I'd already started working on them there at RM request)
Most certainly an enhancement and new feature on top.. we won't be backporting this to 23.05.x :(
In the first patches for this API route a checkout via barcode and patron_id was used but the param barcode got replaced by item_id. If I want to use this API, in my case for checking in/out items via RFID (not SIP2/NCIP), I cannot rely on an item_id as only the barcode is saved on RFID tags. Is it still possible to checkout/checkin items via barcode?
I'd suggest using two API calls.. one to fetch the item by barcode and then a second that uses the item id returned to action the checkout.
> I'd suggest using two API calls.. > one to fetch the item by barcode and then > a second that uses the item id returned to action the checkout. It sounds a bit expensive to me, to fetch an item by its barcode first only to get the item_id. Also fetching an item seems only possible via item_id as the api docs show: GET /api/v1/items/{item_id} I would suggest to check which param is set, either item_id or barcode, and then retrieve the item by the given param
(In reply to Jan Kissig from comment #65) > > I'd suggest using two API calls.. > > one to fetch the item by barcode and then > > a second that uses the item id returned to action the checkout. > > It sounds a bit expensive to me, to fetch an item by its barcode first only > to get the item_id. Also fetching an item seems only possible via item_id as > the api docs show: > GET /api/v1/items/{item_id} > > I would suggest to check which param is set, either item_id or barcode, and > then retrieve the item by the given param I think you would use "List items" with a query for the barcode.
Of course, we're open to follow-up enhancements atop this functionality. An example of the API in use in practice can be seen in the trusted self checkout development.. code visible here: https://git.koha-community.org/Koha-community/Koha/src/branch/master/koha-tmpl/opac-tmpl/bootstrap/js/modals/checkout.js I'd be happy for a barcode based lookup option to be added somewhere into the mix.. just need a clear and consistent way of exposing it.