I think it is nearly impossible to avoid a "U" api in reality and it is not conflict with the business operation APIs.
Use the bank account example, there must be some information that user could change, like name, alias and etc. They could either be changed separately or together. So logically there could be 3 or more operations to do some update,
UpdateName
UpdateAlias
UpdateNameAndAlias
Instead of model them as 3 different business operations, I think it will be modeled as single "UpdateInfo" operation.
In an information management domain, it is common that there is a "Update" operation that could change any fields. I could not think of a reason not naming the API as "update".
I don't like the generic "Update" API but it seems inevitable for any entity that contains mutable information input directly by user.
I really hope to see your thoughts on this. Thanks
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think it is nearly impossible to avoid a "U" api in reality and it is not conflict with the business operation APIs.
Use the bank account example, there must be some information that user could change, like name, alias and etc. They could either be changed separately or together. So logically there could be 3 or more operations to do some update,
Instead of model them as 3 different business operations, I think it will be modeled as single "UpdateInfo" operation.
In an information management domain, it is common that there is a "Update" operation that could change any fields. I could not think of a reason not naming the API as "update".
I don't like the generic "Update" API but it seems inevitable for any entity that contains mutable information input directly by user.
I really hope to see your thoughts on this. Thanks