https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38226 --- Comment #11 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Hi all. I picked the RPC keyword only because I wanted a namespace that makes it clear that endpoints defined in it are not RESTful. I don't see an issue with having a non-RESTful portion of the API for special uses (I'm actually 100% onboard with that), as not everything falls into the CRUD pattern. As an example of this, I'm sure we shouldn't be using the CRUD endpoints for displaying dropdowns. It makes endpoints permissions requirements a real mess e.g. why do you need to access the full library objects in order to display a list of library code/name? Library information is *almost* trivial and not important, but think of other resources. In another context I proposed we made this batch-like endpoints just be `POST /jobs` (or `POST /jobs/batch_cancel_holds`) and this could be better case here. We just need a pattern to follow. That said, the 'RPC nature' on this two introduced endpoints is the fact there's a verb in the path: 'populate_empty_callnumbers'. This particular endpoint is self-documented so I assume Jonathan refers to the guidelines this time. I agree we should document it, if we decide to go this path. As I said, I'd prefer some sort of `POST /jobs` but it would require the consumer to retrieve the job results, etc. Unless we use a pseudo job that (i.e. nothing is queued, etc). (In reply to Jonathan Druart from comment #10)
%curl -X POST -u koha:koha http://localhost:8081/api/v1/rpc/biblios/1/items/99/ populate_empty_callnumbers {"error":"Callnumber fields not found","error_code":"missing_configuration"}
There is no item_id=99 for biblio_id=1. Shouldn't we return 404 instead?
That's a bug. Thanks for taking the time to test it :-D -- You are receiving this mail because: You are watching all bug changes.