4 ms·

Why do you need to be liberal in what you accept, regarding to API? It just invites for subtle bugs. It makes sense for user-generated input, like phone numbers

Why do you need to be liberal in what you accept, regarding to API? It just invites for subtle bugs. It makes sense for user-generated input, like phone numbers or addresses. But for software? You're encouraging buggy incomplete software that'll bite you or your client one way or another with that liberal approach. API must be absolutely strict and unambiguous. It helps everyone in the end. Or you'll end up with parseInt abomination. And for strict API you need strict validation. Probably better than schema can provide, but schema is a good start with declarative description and proven battle-tested libraries. After request was validated by the schema, you can be sure in some facts, like which properties are not null, which values are numbers and so on. This already helps to eliminate lots of unnecessary code.

akie 5y ago
> This already helps to eliminate lots of unnecessary code. Well, I think you just moved the validation code to another place. Instead of putting it in your app, where (in my opinion) it belongs, you are putting it in a hard-to-read and difficult to understand external JSON file. I'm not sure how that's an improvement.
- IggleSniggle 5y ago
  It’s an improvement because it’s a public contract that can be enforced both client(s) and server(s), and a relatively standardized interface format that is parseable by all manner of tooling. Otherwise, it’s just in your code, where it’s potentially not just “hard-to-read”, but impossible to read for anybody but the authors. That said, I’m partial to other solutions like protobuf, but what can you do.
- pibi 5y ago
  It's really not that hard-to-read or to-write. I have instructed dozens of young developers on that with almost no-supervision and no-issue. It's really pretty straightforward. Also, I can replicate my validations at many levels down the stack: from the client to API-GW to the database model. All with a single definition.
- Too 5y ago
  What is hard to read and difficult to understand about this: schemaValidate(input, { "required": ["price"] "properties": { "price": { "type": "number", "minimum": 0, "maximum": 1000 } }}) vs if (input.hasOwnProperty("price")) throw Error("Missing price property") let price = parseInt(data["price"], 10) if (isNaN(price)) throw Error("Property 'price' is not a number") if (price < 0) throw Error("Property 'price' is negative") if (price > 1000) throw Error("Property 'price' is too high") Not claiming the later is particularly difficult, in fact it's very easy to understand, but it is sligthly more verbose and tedious, for bigger validations it can become even worse. Here the schema turns every 2-3 lines of custom validation code into 1, provides automatic and better error messages of the error cause and acts as a contract which consumers of the api can read or even use to auto generate code, GUI, autocompletion. For the later use cases you would of course put the schema in a separate public file. For more complex validation you can of course add them after calling schemaValidate.

akie 5y ago

> This already helps to eliminate lots of unnecessary code. Well, I think you just moved the validation code to another place. Instead of putting it in your app, where (in my opinion) it belongs, you are putting it in a hard-to-read and difficult to understand external JSON file. I'm not sure how that's an improvement.

IggleSniggle 5y ago
It’s an improvement because it’s a public contract that can be enforced both client(s) and server(s), and a relatively standardized interface format that is parseable by all manner of tooling. Otherwise, it’s just in your code, where it’s potentially not just “hard-to-read”, but impossible to read for anybody but the authors. That said, I’m partial to other solutions like protobuf, but what can you do.
pibi 5y ago
It's really not that hard-to-read or to-write. I have instructed dozens of young developers on that with almost no-supervision and no-issue. It's really pretty straightforward. Also, I can replicate my validations at many levels down the stack: from the client to API-GW to the database model. All with a single definition.
Too 5y ago
What is hard to read and difficult to understand about this: schemaValidate(input, { "required": ["price"] "properties": { "price": { "type": "number", "minimum": 0, "maximum": 1000 } }}) vs if (input.hasOwnProperty("price")) throw Error("Missing price property") let price = parseInt(data["price"], 10) if (isNaN(price)) throw Error("Property 'price' is not a number") if (price < 0) throw Error("Property 'price' is negative") if (price > 1000) throw Error("Property 'price' is too high") Not claiming the later is particularly difficult, in fact it's very easy to understand, but it is sligthly more verbose and tedious, for bigger validations it can become even worse. Here the schema turns every 2-3 lines of custom validation code into 1, provides automatic and better error messages of the error cause and acts as a contract which consumers of the api can read or even use to auto generate code, GUI, autocompletion. For the later use cases you would of course put the schema in a separate public file. For more complex validation you can of course add them after calling schemaValidate.