Validating request payload client side

[waterlink]

I can't see if it is possible. For sure in default generated client wrong request payloads actually reach the server.

Since client already has the whole schema, it should be possible to verify request payload to fallback faster.

Probably one wouldn't want to run this validation in production (to not waste resources on checking schema on both sides: client and server).

Another question: Does client validate responses from server?

[geemus]

I don't think it is doing the validations on the client side for requests or responses, though it certainly could. I would tend to agree that this would be really useful, but would probably be a good thing to have configurable (so you could run it in dev/test/staging but maybe not prod).

[waterlink]

So, I'm looking at these two files:

• https://github.com/interagent/committee/blob/master/lib/committee/response_validator.rb
• https://github.com/interagent/committee/blob/master/lib/committee/request_validator.rb

Looks like that is exactly logic that is needed to make these validations. But it is in committee gem, which is a set of rack middlewares, and because of it, depending on it here and using its inner classes would be strange to me.

Do you think it is a valid point to extract this logic somewhere else and re-use it here and in committee ? Something along the lines of json-schema-support or json-schema-validators gem.

[geemus]

Yeah, we've talked about stuff like that a bit. A good home for it might actually be: https://github.com/brandur/json_schema

[schneems]

Those links are no longer valid, I found this in committee:

https://github.com/interagent/committee/blob/9dd0f9c9f16ed569b58d6ce5b2f22f42a6bf199b/lib/committee/middleware/response_validation.rb

I don't see a huge perf benefit of blocking requests before they reach the server if they don't meet the json schema requirement. Maybe some sort of a debug or lint mode would be interesting. This issue has been open for 5 years with no movement, let's close it. If there's a very compelling future reason then we can open a new issue or re-open this one.