-1

Is it a good idea to make http patch more general and also create a new property or even a new persistent entity if it does not exist. The patch could be general and send http body for different models for example

{
    "model": "User",
    "uuid": "c4daef66-4e34-4973-ad56-b11f37702a6d",
    "name": "Joe Bloggs",
    "email_address": "[email protected]"
}

If the entity does not exist, create it from the class of the given model. If there already is an entity which matches any of the keys (uuid and/or email_address could be key(s)) then update it and the matching entity could have many more properties which are not overwritten (but the complete set of properties could be returned from the method).

If this is something I should do, should I also in some way enable the application to "unpatch" entities to entirely remove a property if it is no longer needed? I see that there is a specific way to do this if I understand correctly. I use the User model taken from webapp2 and I changed it to inherit from google.cloud.ndb.model.Expando (in a python3.7 appengine runtime).

1
  • If you need to do something that doesn't neatly fit into the usual HTTP verbs, POST is the correct choice. Dec 28, 2019 at 23:23

1 Answer 1

1

Is it a good idea to make http patch more general and also create a new property or even a new persistent entity if it does not exist.

HTTP Patch is already sufficiently general to describe these two use cases.

If the Request-URI does not point to an existing resource, the server MAY create a new resource, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc.

BUT... if you care about "REST", then you want to make sure that you are coloring inside the lines -- an important constraint is that you use semantics and representations that can be understood by general purpose components.

For instance, if you want to PATCH a JSON representation, then you should probably be using application/json-patch+json or application/merge-patch+json as the representation of your patch, rather than trying to define bespoke semantics for application/json payloads.

Or, to put it another way: if you are going to be using custom semantics with custom representations, then you should be using POST, because that's the part of the uniform interface that is designed for messages that aren't worth standardizing (Fielding, 2009).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.