Context:
We expose Shipment
object rest API.
And example data
{id: "abcefg", name: "abc", status:"open", carrier:"UPS", shipFrom:"addres1"...}
Get a shipment API: /shipment/abcefg
My question is how to design the update related APIs in a complex resource?
One way to do update will looks like below url
Path /shipment/abcefg
We enable client to update each field in the shipment. Client can provide updated fields to the payload. The issue is that, Shipment is a huge object. The update can become complex. Especially the status update. we need to apply a lot of rules and actions before we change status. E.g.: When shipment close, we do a validation, send email, send SNS topic....
Alternative 1:
Path /shipment/abcefg Disable status update in the shipment update
Path /shipment/abcefg/status/open /shipment/abcefg/status/close .....
Issue with this approach is that we had a verb in the url, and we also need to create a lot of url bases on numbers of status.
Alternative 2:
Path /shipment/abcefg Disable status update in the shipment update We split Status out of shipment and provide another API
Path /shipment/status Client will provide open
,close
in the playload.
The issue with this approach is that we combine all those status update method into one method, which make this status update method more complex.
Does anyone have a suggestion for us to pick the right design? Thank you very much.
Aucun commentaire:
Enregistrer un commentaire