Design Patterns – Designing Function-Based RESTful API

api-designdesigndesign-patternsrestrpc

Please settle an argument between me and a friend.

We'r currently designing a product API. Our Product entity looks like this

{
    "Id": "",
    "ProductName": "",
    "StockQuantity": 0
}

Product sales are handled by a 3rd party and they are obligated to inform us with the purchased quantity so StockQuantity field can be decreased.

My approach:

PUT /api/Product/{Id}/ --data { "StockQuantity": "{NewStockQuantity}" }

The 3rd party is responsible with querying the product, making the calculation based on current StockQuantity and purchased quantity and sending a PUT request with the new value.

My friend does not want the 3rd party to do the calculation. His approach

PUT /api/Product/{Id}/DecreaseStock --data { "PurchasedQuantity": "{PurchasedQuantity}" }

So we can make the calculation and update the StockQuantity

I don't want to create function based endpoints and he don't want to trust on 3rd party to make the calculations.

What would be the correct way for us to approach this problem?

Best Answer

You could let your 3rd party post sales to your product. For example:

POST /product/{id}/sale { "Quantity": 3 }

I agree with both your and your colleague's point. This is business logic, and shouldn't be left to the client of the API, but you should also avoid having "functions" as endpoints.

Sometimes solving such problems is as easy as calling it differently, admittedly not always.

Related Topic