DEV Community

Discussion on: Making Better HTTP APIs

Collapse
javiercane profile image
Javier Ferrer

I've worked with a similar approach, the difference was to do not rely on the server in order to generate the identifiers. I mean, it's the client who actually generate the identifier (UUID), and tells to the server all the resource details (including the identifier).

This way we would avoid having to always make the first POST request, and something also important, not having to return something such as the assigned identifier in this POST call response. This last concern is derived form CQRS concepts where the commands doesn't return information.

Thanks for sharing!

Collapse
orkon profile image
Alex Rudenko Author

Thanks for the comment. Getting away with a PUT request only would be great but I am sure it's not always desirable to let clients decide on identifiers. Nevertheless, if possible, it's definitely better!

Collapse
javiercane profile image
Javier Ferrer

Just curious because maybe you've faced different scenarios which would justify that assertion. In which cases you would find not desirable to let the client decide on the resources identifiers?

Thx!

Thread Thread
orkon profile image
Alex Rudenko Author

Mostly for these three reasons:

  • when IDs need to have a special format. For example, sequential, prefixed or have some other rules. This could be desired for different purposes, mostly, for easier handling by humans (uuid is less readable and quite long)
  • to avoid conflicts between different clients (if it's not uuid)
  • to simplify implementation of the clients which I cannot control (it could be wrong etc and it may be working only by accident)
Thread Thread
javiercane profile image
Javier Ferrer

My point of view:

  • IDs need to have a special format: In that case I would go for not having such "human readable identifier" as the actual resource identifier. I mean, we could have the resource identifier represented by an UUID, and an additional field with such format.
  • Avoid conflicts: As you said, this wouldn't be the case while using UUIDs.
  • Clients which I cannot control: The proposed solution would make the clients perform 2 different requests (POST + PUT), so it would be strange for a client being able to do so but not being able to generate an UUID and making one PUT request.
  • It may be working only by accident: If the client generates an invalid UUID it will throw an error such as invalid request from the server, or if the identifier is not generated randomly, it will throw an error while trying to save it, leaving no margin for this hypothesis, doesn't it?

Thanks for sharing!

Thread Thread
orkon profile image
Alex Rudenko Author • Edited on

Thanks for the comment! I agree that what you suggest is a good solution and can work well for many use cases. But 1) you cannot always choose UUID as id for different reasons and an additional generated id may not help (if you can, use UUID though) 2) UUID generation on clients you don't control can break at any time in production if done wrong and then you will have frustrated users who always get an error. So what you say: give the clients a chance to mess up; what I say: give the clients no chance to mess up at the expense of two HTTP requests. You can decide what to do in any given case and if you want to optimize the two requests and compress the logic into one. But if the operation is quite important I would advocate for paying the price of two requests but having full control over IDs on the backend and making sure nothing can be messed up (by anyone except you as the backend developer)

Thread Thread
javiercane profile image
Javier Ferrer

👍👍👍

Thanks for the reply!