Respond with an error when a request is invalid, based on JSON Schema.
It would be nice if Apiary responded with a 400 Bad Request if the request body did not validate against a given JSON Schema. The response body should contain the validation error message/instructions.
no, it isn't as we are still not sure how many people would this annoy instead of helping them (in the prototyping phase) given that not many devs are using JSON Schema.
I think it may be bumped after MSON is completely done, significantly increasing amount of people using it.
Romain Pellerin-Rezzi commented
Is this already implemented?
just as a thought — how would you like to decide which key is significant for the matching?
Marco Cattai commented
I agree, I would like to create a Json validation schema for the payload and have a 400 Bad Request only when the payload is not conform to the schema.
If the payload is conform to the schema I would like to be able to decide what kind of mocked 201 response give back as response. I would be able to decide the mock basing on the value of a particular key into the payload.
Kelly Campbell commented
I was just searching the documentation for something like this X-Apiary-Validation-Status header, so that would be great to have. Either that, or an api into the traffic inspector. Thanks!
Dan Trenz commented
I guess what it comes down to is that a lot of Apiary users would really like Apiary to behave like a real API as much as possible w/o actual scripting or business logic, etc. That way, API consumers could integrate against Apiary while the actual API is being developed.
It seems like it would be useful for the mock API to be able to use JSON Schema validation to notify clients/consumers when they are sending in malformed/invalid requests. This would save a lot of headaches when the real API comes online, and we discover that requests that were seeming valid in Apiary, are actually invalid.
Long story short, a custom response header is not something that consumers should have to look for, nor would they even think to if the mock API is returning a successful response body w/ 200 OK.
A HTTP 400 Bad Request error with the validation error message in the response body would be far more useful.
I get the idea, but it doesn't fit with some use-cases.
Would X-Apiary-Validation-Status header suffice?