CODEWITHSUNDEEP
restapihttppost
YK S
YK S

Reputation: 3430

Validating HTTP POST request body for a REST API

We are thinking about different kind of validations for POST request body on server side.

Should we have a strict schema for POST request body and throw 4xx errors when user's request contains extra fields other than mentioned in the schema.

Also, I came across following while searching:

More importantly, schema validation is generally not a good idea in a REST service. A major goal of REST is to decouple client and server so that they can evolve separately.

Does the above means that user can send unnecessary data also in request body?

Upvotes: 2

Views: 4123

Answers (2)

Evert
Evert

Reputation: 99776

I would absolutely strictly validate any incoming data, if you can. Postel's law of 'being liberal in what you accept' is widely accepted as a bad idea.

A big issue is that a client might misspell an optional field and not get feedback on what they should have sent. There's rarely a good reason for a server to just accept garbage values, because generally it's a strong indicator of a bug existing somewhere. It's smart to want that bug to be very visible instead of it being silently ignored.

If you're building an API, use JSON-Schema and be strict.

Upvotes: 3

erik258
erik258

Reputation: 16302

Yes, it does to me. There's no compelling reason to reject a request that you can respond to successfully, just because there's extra data, for reasonable cases (you'd have POST size limits on an API anyway).

The point about decoupled evolution is a good one. Fields come and go; there's no reason not to honor requests made with an outdated definition of which fields are required. I recommend against adding required fields to the same API endpoint for the same reason. At the end of the day, change is the biggest factor of difficulty with APIs, and rigidity only makes the impact of that change more painful. After all, don't we "just" want it to work for our users?

Upvotes: 1

Related Questions