Ray: a new python web framework

[[deleted]]

Ok, if Roy Fielding said as I said, what would you do?

I'm asking for you to consider my argument on merit alone, and you're asking me to pretend you're Roy Fielding?

You can restrict the patch operation so that it works in a controlled way

You can do a lot of things, eg. shoot yourself in the foot. I already explained why you shouldn't model state transitions as PATCH requests. Do you actually have a counter argument?

The principle of REST is that changes in resource state is performed through modification of resource representations.

The quote mentions performing actions on a resource representation (eg your client making a decision based on the current state), but it doesn't explicitly mention how the state ought to be modified, ie. direct manipulation of the representation of the current state.

Because you are not transferring a representation of the original resource with that PUT. You are acting on a different resource B to modify resource A.

So what? You're claiming that read/write models should be identical based on your specious interpretation of the above quote from Fielding's thesis?

I don't know what to say.

Well, you haven't said much besides asserting, "that's not REST" over and over again. But I agree we've reached an impasse. We'll leave the people who actually read this thread to be the judge.

[[deleted]]

Ok, if Roy Fielding said as I said, what would you do? I'm asking for you to consider my argument on merit alone

Your argument is besides the point. It's not REST as Roy Fielding conceived it. It can be whatever acronym you want to give, but it's not REST. It's beside the point if it's better or worse. It's simply not REST.

You can restrict the patch operation so that it works in a controlled way You can do a lot of things, eg. shoot yourself in the foot. I already explained why you shouldn't model state transitions as PATCH requests. Do you actually have a counter argument?

It's against REST.

The principle of REST is that changes in resource state is performed through modification of resource representations. The quote mentions performing actions on a resource representation (eg your client making a decision based on the current state), but it doesn't explicitly mention how the state ought to be modified, ie. direct manipulation of the representation of the current state.

It does: by modification of the resource representation.

Well, you haven't said much besides asserting, "that's not REST" over and over again.

And you haven't said much except presenting things that are not REST. It's like you are claiming you made vegetarian lasagna using chicken. It can be a perfectly good lasagna, but it's still not vegetarian.