Should all the fields be strings?

I cannot find any reference to this in the documentation. Should the client send every field in a string form?
For instance, if an attribute of a resource is age, should I send "age": 23 or "age": "23"?

Attributes may contain any valid JSON value.

Ahh here it is! thank you very much!

@steveklabnik If you don’t mind, I have a further question on this… Say I have an integer column age in a database. Do you think the server should then treat both integers (eg 23) as well as numeric strings ("23") the same, so that clients could transparently send data both in numeric and string values? Or instead the server should make a choice?

Inferred types are evil. Be a good neighbor and be explicit! Future you will love you for it.

@michaelhibay thank you! So, are you for not accepting data (example, in an API, respond with an error) if I am expecting an integer and instead a string is passed?
In particular, in this case, I would refer to error processing and respond with 4xx.

I think you should be very explicit about the contract and options you plan to support with respect to the data types you accept in your messages. If you aren’t explicit in schemas, you add ambiguity, requiring devs to look through your documentation, and if you aren’t there then you have a big problem. Strings are evil, once you start adding odd formats and can get really crazy stuff to happen.