Should a RESTful API's payload model decide the way the api should behave?

Question

Say I have a task entity modelled in my application as { id: "qweqdsad", name:"Drink Coffee", description:"Coffee helps in overcoming laziness", userId:12 }

Now in my application, say the above JSON is the payload for create task endpoint, In this case if I should prevent the user from adding or creating tasks to other users apart from him. Should the api payload be modelled as { id: "qweqdsad", name:"Drink Coffee", description:"Coffee helps in overcoming laziness" }

Note that the userId information is removed from the payload, since the userId information is already available as part of the auth token. Is this method of remodelling the api correct or the api payload structure should always remain the same, while prevention of users adding tasks to other users is prevented by an authorization logic.

To put it simply, should I remodel my entity structure based on the functionality or authorization?

Which one is the right approach to follow here?

Answer 1

A thing to understand is that HTTP constrains message semantics -- what the messages mean -- but it doesn't constrain the server's implementation. See Fielding's 2002 remarks about "safe".

So if you were to do send a request like

PUT /977215bc-80f9-43f5-b95b-bff5be20ca71 HTTP/1.1
Content-Type: application/json

{
  id: "qweqdsad",
  name:"Drink Coffee", 
  description:"Coffee helps in overcoming laziness"
}

The server is free to change that representation if necessary. The specification of PUT actually calls that out

An origin server MUST NOT send a validator header field (Section 7.2), such as an ETag or Last-Modified field, in a successful response to PUT unless the request's representation data was saved without any transformation applied to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request) and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites