Very interesting question. Actually your question is beyond of JSON API (even API design). The solution is different depend on decisions on both client and server side. But I think your problem is:
If one operation for a resource also affects other resources,
- Should the logic of related resources change happen on server side, or client side?
- If 1 is server side, should we notify the client about the change? If so how should we do that?
I recommend you to reconsider the whole design, but let’s assume both above questions are yes first. In your shopping cart example, my solution is to use the operation to modify the “cart” resource other than “cart item” resource. A weird example is using
POST /cart/delete-item but not
DELETE /cart/items/:id. The benefit is, your API response can always return the latest state of the cart (or order). And every time you use the server state to replace the client state.
The reason is, what really matters is the resource, not the url. This applies to all API design. Even in JSON API, using resource name + id as url is a recommendation but not specification. If you aren’t convinced, think about how you query data from database – you can use different queries to get the same record. The same applies to url and resource in API design.
Another way to notify the client is to send the resource changes, but I prefer to send the whole cart state. Because the client doesn’t need to know how to apply those changes, it just re-render the cart and related resources (like the page refreshes). Even your requirement changes in future – like adding new kind of resources under the cart – the client is not affected.
For comparison, I can give you another cart solution from one of my previous projects. The requirement is alomos the same, and we decided to preload all promitions on the client and let it to manage all cart order changes, because it’s an tablet app, we can consider it’s safer than web browser and we need every action to have instant response. When the client prepared the order, it used
POST /orders to submit all related resources to the server. We also do validations on server side to make sure all promotions are used correctly. Although we have slightly logic duplication on both client and server, it’s reasonable in the whole system’s viewpoint.