Overview: The /circulation/rules/request-policy endpoint requires four URL params for a GET request: item type ID, loan type ID, patron type ID, and location ID, all in the form of UUIDs. If any of the first three IDs doesn't match an actual value in the system (e.g., a nonexistent loan type is specified), the API returns a 200 response – the query is valid, it just isn't able to find a match for the query. However, if an invalid location UUID is submitted, the server responds with a 500 error. (I realize now that this may be a deliberate choice, albeit inconsistently applied – see "Additional information" below.)

Steps to Reproduce:

1. In the FOLIO environment of your choice, obtain sample UUIDs needed for the call. This is perhaps easiest done using Postman or a similar tool to get the following:

   1. item type ID: GET /material-types (choose any)

   2. loan type ID: GET /loan-types (choose any)

   3. patron type ID: GET /users, choose a patronGroup value from one of the entries

   4. location ID: GET /locations (choose any)

2. Do a GET /circulation/rules/request-policy with the four values added as URL params:  /circulation/rules/request-policy?item_type_id=<value>&loan_type_id=<value>&patron_type_id=<value>&location_id=<value>

3. For a valid location ID, confirm that the response is OK (200)

4. Change the UUID to a value that doesn't exist in the system. The response should be a 500 error

Expected Results: Submitting an invalid location ID still results in a 200 response

Actual Results: An invalid location ID produces a 500 error response

Additional Information:

I just noticed that the error, on folio-snapshot, includes the helpful hint "location not found" (it's a different message in Cornell's hosted instance). That suggests that the choice of a 500 response is deliberate. I'm neutral on the point of whether the API should return a 200 or a 500 for an invalid UUID; but in either case, I think the response should be consistent if any of the parameters is invalid.

Interested parties: Cornell