validation - API Craft | Google Groups

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion validation
Received-SPF: pass (google.com: domain of cappela...@gmail.com designates 209.85.216.177 as permitted sender) client-ip=209.85.216.177;
From: Pat Cappelaere <cappela...@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_19382E1C-4298-4AD5-9764-8D7F709C2844"
Message-Id: <C88B45FD-9E6E-4DDF-9687-4410F559C...@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
Subject: Re: [api-craft] validation
Date: Wed, 26 Sep 2012 11:32:46 -0400
References: <309e7868-f504-44b8-8646-e891213c4167@googlegroups.com> <CAK5Vdzzren=BnA3zt9+WjePmntAW4RwNi=YYtbmuiApSEyG...@mail.gmail.com> <d53033fb-c462-413c-b1a9-e933dcc6fd92@googlegroups.com>
To: api-craft@googlegroups.com
In-Reply-To: <d53033fb-c462-413c-b1a9-e933dcc6fd92@googlegroups.com>


--Apple-Mail=_19382E1C-4298-4AD5-9764-8D7F709C2844
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Runtime message validation on the server side is pretty critical to me.
You do not have to use a schema but if you had one, you could use it for =
validation and you could inform your client of your validation rules.
Client can then use it any way it wants (or even ignore it).  Seems a =
win-win to me=85
Pat.

On Sep 26, 2012, at 11:26 AM, Andrei Neculau <andrei.necu...@gmail.com> =
wrote:

> Peter, I would say that you took my answer too much ad-literam. In =
practice, I am going to use JSON schema validation.
>=20
> If you ignore schema validation, my question is also valid up to the =
point where you have to decide whether you allow or not allow unknown =
properties to be sent.
> Do you accept unknown data and terminate successfully  or do you barf =
saying "talk (my) language" ?
>=20
> If I try to simplify my analysis: the former is deceiving.
> I tell you "please bring me water and an aspirine" and you come back =
with aspirine "you're welcome!" -> (o.O)
>=20
> On Wednesday, September 26, 2012 5:05:46 PM UTC+2, Peter Williams =
wrote:
> I think schema validation is a pretty horrible idea, except as a =
design time debugging tool. Even that role is better served by a =
validation program. Schema languages are rarely powerful enough to fully =
specify message requirements (eg, numbers that must be inside a =
particular range, strings that must have particular structures, etc).
>=20
> Disadvantages of strict runtime validation:
>=20
> * introduces unnecessary failures for messages that don't conform but =
that would be usable by the recipient
> * makes introducing new properties awkward. New properties must be =
optional so as to not break existing clients even if you would really =
prefer all clients send them.
> * inefficient because the message must be interpreted extra times. =
Once by the recipient to accomplish its goal, and one additional time =
for each schema validation.
>=20
> I think schema based message validation provides very little value and =
requires a fair bit of work. You'd be better off using that time =
implementing really good error messages on the server side.
>=20
> Peter
> barelyenough.org
>=20
> On Sep 26, 2012 6:44 AM, "Andrei Neculau" <andrei....@gmail.com> =
wrote:
> >
> > This might be an obvious decision (it is for me, but as you will see =
my analysis is skewed and biased below),
> > but since I need to defend it in front of non-tech people, thought =
of fishing for opinions/experiences
> >
> > Strict validation:
> > + fail fast
> > any integration mishaps will surface asap, and the API will give =
descriptive errors for totally unknown or misspelled or mistyped =
properties (eg. unknown field <adres>, maybe <address>? or =
post_letter_at must be a timestamp, not a ISO string, etc)
> > + inherent memory optimization
> > if there is more data being sent than you actually know how to =
process, you will free up memory instantly by throwing an error. That =
gets even worse if you work with functional programming and you pass =
contexts around, which may care useless data around.
> > + inherent clean client-server contract
> > server says "send me something that i know how to process, and i =
will do what you (client) expect me to do"
> >
> > Loose validation:
> > 0 (a fake impression that) integration is smoother
> > since sending unknown properties still allows for successful API =
requests
> > 0 (a fake impression that) you will get more useful data now
> > just that you don't know what to do with it, other than store it,
> > but that in the future you will get the chance to analyze it one way =
or the other
> > + memory optimization is still possible
> > if you clean up the request data and only keep data that you know =
how to process
> > - fuzzy client-server contract
> > server says "send me something, and i will pick what i want from it, =
and do something that you might or might not expect me to do" eg. sell =
car X to _persson_ Y, server doesn't understand persson, but only =
person, but it has the feature to simply sell the car to nobody (ie. put =
the car on the market for sale), server responds 200 OK and it is up to =
the client to fix the mess
> >
> > thank you for your time.
> >
> > --=20
> > You received this message because you are subscribed to the Google =
Groups "API Craft" group.
> > To unsubscribe from this group, send email to =
api-craft+...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/api-craft?hl=3Den.
> > =20
> > =20
>=20
> --=20
> You received this message because you are subscribed to the Google =
Groups "API Craft" group.
> To unsubscribe from this group, send email to =
api-craft+unsubscribe@googlegroups.com.
> Visit this group at http://groups.google.com/group/api-craft?hl=3Den.
> =20
> =20


--Apple-Mail=_19382E1C-4298-4AD5-9764-8D7F709C2844
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Runtime message validation on the server side is pretty critical to =
me.<div>You do not have to use a schema but if you had one, you could =
use it for validation and you could inform your client of your =
validation rules.</div><div>Client can then use it any way it wants (or =
even ignore it). &nbsp;Seems a win-win to =
me=85</div><div>Pat.</div><div><br><div><div>On Sep 26, 2012, at 11:26 =
AM, Andrei Neculau &lt;<a =
href=3D"mailto:andrei.necu...@gmail.com">andrei.necu...@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Peter, I would say that you took my answer too much =
ad-literam. In practice, I am going to use JSON schema =
validation.<div><br><div>If you ignore schema validation, my question is =
also valid up to the point where you have to decide whether you allow or =
not allow unknown properties to be sent.</div><div>Do you accept unknown =
data and terminate&nbsp;successfully&nbsp; or do you barf saying "talk =
(my) language" ?</div><div><br></div><div>If I try to simplify my =
analysis: the former is deceiving.</div><div>I tell you "please bring me =
water and an aspirine" and you come back with aspirine "you're welcome!" =
-&gt; (o.O)<br><br>On Wednesday, September 26, 2012 5:05:46 PM UTC+2, =
Peter Williams wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p =
dir=3D"ltr">I think schema validation is a pretty horrible idea, except =
as a design time debugging tool. Even that role is better served by a =
validation program. Schema languages are rarely powerful enough to fully =
specify message requirements (eg, numbers that must be inside a =
particular range, strings that must have particular structures, =
etc).</p><p dir=3D"ltr">Disadvantages of strict runtime =
validation:</p><p dir=3D"ltr">* introduces unnecessary failures for =
messages that don't conform but that would be usable by the =
recipient<br>
* makes introducing new properties awkward. New properties must be =
optional so as to not break existing clients even if you would really =
prefer all clients send them.<br>
* inefficient because the message must be interpreted extra times. Once =
by the recipient to accomplish its goal, and one additional time for =
each schema validation.</p><p dir=3D"ltr">I think schema based message =
validation provides very little value and requires a fair bit of work. =
You'd be better off using that time implementing really good error =
messages on the server side.</p><p dir=3D"ltr">Peter<br>
<a href=3D"http://barelyenough.org/" =
target=3D"_blank">barelyenough.org</a></p><p dir=3D"ltr">On Sep 26, 2012 =
6:44 AM, "Andrei Neculau" &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"icn9qTx4QKsJ">andrei....@gmail.com</a>&gt; =
wrote:<br>
&gt;<br>
&gt; This might be an obvious decision (it is for me, but as you will =
see my analysis is skewed and biased below),<br>
&gt; but since I need to defend it in front of non-tech people, thought =
of fishing for&nbsp;opinions/experiences<br>
&gt;<br>
&gt; Strict validation:<br>
&gt; + fail fast<br>
&gt; any integration mishaps will surface asap, and the API will give =
descriptive errors for totally unknown or misspelled or mistyped =
properties (eg. unknown field &lt;adres&gt;, maybe &lt;address&gt;? or =
post_letter_at must be a timestamp, not a ISO string, etc)<br>

&gt; + inherent memory optimization<br>
&gt; if there is more data being sent than you actually know how to =
process, you will free up memory instantly by throwing an error. That =
gets even worse if you work with functional programming and you pass =
contexts around, which may care useless data around.<br>

&gt; + inherent clean client-server contract<br>
&gt; server says "send me something that i know how to process, and i =
will do what you (client) expect me to do"<br>
&gt;<br>
&gt; Loose validation:<br>
&gt; 0 (a fake impression that) integration is smoother<br>
&gt; since sending unknown properties still allows for successful API =
requests<br>
&gt; 0 (a fake impression that) you will get more useful data now<br>
&gt; just that you don't know what to do with it, other than store =
it,<br>
&gt; but that in the future you will get the chance to analyze it one =
way or the other<br>
&gt; + memory optimization is still possible<br>
&gt; if you clean up the request data and only keep data that you know =
how to process<br>
&gt; - fuzzy client-server contract<br>
&gt; server says "send me something, and i will pick what i want from =
it, and do something that you might or might not expect me to do" eg. =
sell car X to _persson_ Y, server doesn't understand persson, but only =
person, but it has the feature to simply sell the car to nobody (ie. put =
the car on the market for sale), server responds 200 OK and it is up to =
the client to fix the mess<br>

&gt;<br>
&gt; thank you for your time.<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google =
Groups "API Craft" group.<br>
&gt; To unsubscribe from this group, send email to <a href=3D"javascript:"=
 target=3D"_blank" =
gdf-obfuscated-mailto=3D"icn9qTx4QKsJ">api-craft+...@<wbr>googlegroups.com=
</a>.<br>
&gt; Visit this group at <a =
href=3D"http://groups.google.com/group/api-craft?hl=3Den" =
target=3D"_blank">http://groups.google.com/<wbr>group/api-craft?hl=3Den</a=
>.<br>
&gt; &nbsp;<br>
&gt; &nbsp;<br>
</p>
</blockquote></div></div><div><br =
class=3D"webkit-block-placeholder"></div>

-- <br>
You received this message because you are subscribed to the Google =
Groups "API Craft" group.<br>
To unsubscribe from this group, send email to <a =
href=3D"mailto:api-craft+unsubscribe@googlegroups.com">api-craft+unsubscri=
be@googlegroups.com</a>.<br>
Visit this group at <a =
href=3D"http://groups.google.com/group/api-craft?hl=3Den">http://groups.go=
ogle.com/group/api-craft?hl=3Den</a>.<br>
&nbsp;<br>
&nbsp;<br>
</blockquote></div><br></div></body></html>=

--Apple-Mail=_19382E1C-4298-4AD5-9764-8D7F709C2844--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
