0

What is the best practice for a response if the user tries to write to a field he or she is not allowed?

Imagine the user wants to create a resource, for example a pizza: POST /pizza

The body:

{
  "name": "Hawaii",
  "base": "tomato sauce",
  "firstMain": "ham",
  "secondMain": "pineapple",
  "cheese": true
}

Problem is, you can't put secondMain on a pizza (because its pineapple). What's better? Return a 403 error with the message that field secondMain is not writable or return a 201 with the created pizza but without the secondMain?

What's the best practice for this problem? Didn't found anything on Google.

0x4b50
  • 629
  • 6
  • 18

1 Answers1

1

Returning a 403 with a proper error response would work best. Saying 201 but creating something different then what they originally wanted would probably lead to a unhappy customer. I know I'd be annoyed if my pizza didn't come with pineapple and that's what I ordered.

Really guess it varies on a case by case basis depending on your expected result and what your client is expecting to happen. Just make sure to specify in your documentation that extra data sent up with requests that isn't writable will throw an error.

etc

403 response: {error: {"secondMain": "unknown field", "exampleField": "expected but missing"}}

matt
  • 1,680
  • 1
  • 13
  • 16
  • sounds good. Actually I'm the customer using an API. The API returns a 403 but only specifying the not writable field with an id. As I don't have insight into the internal id mappings I wondered if that is a best practice. Thank you! – 0x4b50 Jul 31 '20 at 14:03
  • @0x4b50 ah! I would definitely send them an email, asking for better error responses. probably a feedback they've never gotten. Cheers. – matt Jul 31 '20 at 14:13
  • I did. Unfortunately they are not really fast in responding :/ – 0x4b50 Aug 01 '20 at 09:22