0

Having the entity Client and a rest api for it, I can think of two restpoint PATCH methods, one from a screen that modifies just some attributes and the other from calling a webservice that register an existing client in some third party system and alter some attribute on it. The points is that both methods would have the same PATCH HTTP verb and URI path like PATCH myApp/v1/clients/12345

This is just an example but I could think of many more PATCH methods with the same URI, so in order to avoid duplications in the URIs and give some meaning URIs for this cases to the caller of this API:

  • Could I just add to the end of the path for registering an existing client in some third party system the next? myApp/v1/clients/12345/registerInThirdPartySystem . Is it bad? Is it not restful? Any other ideas?

Thanks

fernando1979
  • 1,727
  • 2
  • 20
  • 26

1 Answers1

0

Conceptually the body of a PATCH is intended to describe how you are modifying the resource at the URI.

So if your resource at /myApp/v1/clients/12345 represents a client, then any PATCH requests on that endpoint I would expect to change the entity.

Similarly, if I did a patch request on /myApp/v1/clients/12345/registerInThirdPartySystem, I would expect the purpose of this request is to update the "registerInThirdPartySystem" resource, which is nonsensical.

The registerInThirdPartySystem to me sounds like an RPC operation, so to me the appropriate method for this would be POST.

If the different PATCH operations you are describing do change the "client" itself, you should keep the URI pointing to the "client" and differentiate the request by their media-type and/or body.

Evert
  • 93,428
  • 18
  • 118
  • 189