Hi Wendy, Good comment!
On Wed, Oct 9, 2013 at 3:37 PM, Wendy Roome <[email protected]>wrote: > Do we really need a separate E_INVALID_FIELD_TYPE error code? Why not > just fold it into E_MISSING_FIELD, by defining that as "The field is > missing or it has the wrong type." > > First reason it's unnecessary: if the protocol says the client must > provide a String field named "cost-type", and the client defines > "cost-type" as an array, well, the STRING field is missing, isn't it? > > Second reason: JSON libraries rarely distinguish between "missing" and > "wrong type". Eg, getString("foo") usually returns null if "foo" doesn't > exist or if it exists but isn't a string. The server has to do additional > analysis to distinguish between the two cases. > > Suppose one uses Data Binding (e.g., http://wiki.fasterxml.com/JacksonInFiveMinutes) for deserialization. A wrong type, in a strong typed language, will cause the deserialization to fail, depending on specified features ( https://github.com/FasterXML/jackson-databind/wiki/Deserialization-Features). Hence, if one uses a strict parser, a wrong type (e.g., a number but should be a string) will cause the parser to fail, and the server may only know that it is a syntax error E_SYNTAX. I agree that a missing field will cause the same. In this sense, they are all syntax errors in a PL sense. Hence, a more appropriate coarse error is E_SYNTAX. In this sense, E_SYNTAX is a base class of two specific sub types (missing or wrong type). What do you think? > Third reason: Does distinguishing "missing" from "wrong type" really help > the client? Fundamentally its the same error. The client programer will > check the definition of the field and will figure it out pretty quickly. > > If a server can distinguish between these two: it can be helpful to a client. For example, a programmer might specified a number for a string, and can be wondering why the server says that the field is missing when there is the field there. Saying that it is a wrong type can be helpful, if the server can. Thanks a lot for the always great catch! Richard > - Wendy Roome > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
