PATCH support…finally.

I added PATCH support to the Costs to Expect API in November. At the time I did the minimum, I only added PATCH support for items as that was the only data we needed to edit.

In March, I reviewed the PATCH code, making a few minor alterations.

It is now time to add PATCH support to the rest of the API. PATCH support will be added for resource types, resources, categories, subcategories and category assignments for items.

When I reviewed the PATCH code in March, I was looking at a single instance. This time I need to implement PATCH support across multiple routes; we will see how many changes I make in attempting to make the code DRY.

I have six tickets in my tracker, one for each route plus one additional chore for minor refactoring. If everything goes well, I should have a release ready in a few days, and I shouldn’t have created any extra refactoring chores.

Override pagination limits

Pagination is necessary; you don’t want your API/website/app to default to returning everything from the database, occasionally though you might want to fetch the entire collection.

On the Costs to Expect API, we have added a collection parameter, if set to true the pagination limits do not apply, and the entire collection is requestable.

There are a couple of caveats, the API defaults the parameter to false, and we only allow the parameter for collections which will know will be limited in size.