Received: by 10.58.187.17 with SMTP id fo17mr200739vec.37.1348673339377;
Wed, 26 Sep 2012 08:28:59 -0700 (PDT)
X-BeenThere: api-craft@googlegroups.com
Received: by 10.220.154.5 with SMTP id m5ls1136188vcw.2.gmail; Wed, 26 Sep
2012 08:28:57 -0700 (PDT)
Received: by 10.52.156.115 with SMTP id wd19mr282273vdb.2.1348673337865;
Wed, 26 Sep 2012 08:28:57 -0700 (PDT)
Date: Wed, 26 Sep 2012 08:28:57 -0700 (PDT)
From: Andrei Neculau <andrei.necu...@gmail.com>
To: api-craft@googlegroups.com
Message-Id: <f77892ea-ea82-41bb-bda1-85c0d074de44@googlegroups.com>
In-Reply-To: <CANqiZJYiO2dd0emF+5Aep58GigfjZOxWygtP3BbuO2dK7dePWw@mail.gmail.com>
References: <309e7868-f504-44b8-8646-e891213c4167@googlegroups.com>
<CAK5Vdzzren=BnA3zt9+WjePmntAW4RwNi=YYtbmuiApSEyGSzw@mail.gmail.com>
<CANqiZJYiO2dd0emF+5Aep58GigfjZOxWygtP3BbuO2dK7dePWw@mail.gmail.com>
Subject: Re: [api-craft] validation
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_376_6492369.1348673337654"
------=_Part_376_6492369.1348673337654
Content-Type: multipart/alternative;
boundary="----=_Part_377_31796067.1348673337654"
------=_Part_377_31796067.1348673337654
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Mike, you made my day =)
On Wednesday, September 26, 2012 5:19:07 PM UTC+2, Mike Kelly wrote:
>
> it's all just prickles and goo:
>
> http://www.youtube.com/watch?v=XXi_ldNRNtM
>
> On Wed, Sep 26, 2012 at 4:05 PM, Peter Williams <pe...@barelyenough.org<javascript:>>
> 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).
> >
> > Disadvantages of strict runtime validation:
> >
> > * 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.
> >
> > 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.
> >
> > Peter
> > barelyenough.org
> >
> > On Sep 26, 2012 6:44 AM, "Andrei Neculau" <andrei....@gmail.com<javascript:>>
> 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.
> >>
> >> --
> >> 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 <javascript:>.
> >> Visit this group at http://groups.google.com/group/api-craft?hl=en.
> >>
> >>
> >
> > --
> > 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 <javascript:>.
> > Visit this group at http://groups.google.com/group/api-craft?hl=en.
> >
> >
>
>
>
> --
> Mike
>
> http://twitter.com/mikekelly85
> http://github.com/mikekelly
> http://linkedin.com/in/mikekelly123
>
------=_Part_377_31796067.1348673337654
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
Mike, you made my day =)<br><br>On Wednesday, September 26, 2012 5:19:07 PM UTC+2, Mike Kelly wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">it's all just prickles and goo:
<br>
<br><a href="http://www.youtube.com/watch?v=XXi_ldNRNtM" target="_blank">http://www.youtube.com/watch?<wbr>v=XXi_ldNRNtM</a>
<br>
<br>On Wed, Sep 26, 2012 at 4:05 PM, Peter Williams <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="O5ZXcGCJmcsJ">pe...@barelyenough.org</a>> wrote:
<br>> I think schema validation is a pretty horrible idea, except as a design time
<br>> debugging tool. Even that role is better served by a validation program.
<br>> Schema languages are rarely powerful enough to fully specify message
<br>> requirements (eg, numbers that must be inside a particular range, strings
<br>> that must have particular structures, etc).
<br>>
<br>> Disadvantages of strict runtime validation:
<br>>
<br>> * introduces unnecessary failures for messages that don't conform but that
<br>> would be usable by the recipient
<br>> * makes introducing new properties awkward. New properties must be optional
<br>> so as to not break existing clients even if you would really prefer all
<br>> clients send them.
<br>> * inefficient because the message must be interpreted extra times. Once by
<br>> the recipient to accomplish its goal, and one additional time for each
<br>> schema validation.
<br>>
<br>> I think schema based message validation provides very little value and
<br>> requires a fair bit of work. You'd be better off using that time
<br>> implementing really good error messages on the server side.
<br>>
<br>> Peter
<br>> <a href="http://barelyenough.org" target="_blank">barelyenough.org</a>
<br>>
<br>> On Sep 26, 2012 6:44 AM, "Andrei Neculau" <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="O5ZXcGCJmcsJ">andrei....@gmail.com</a>> wrote:
<br>>>
<br>>> This might be an obvious decision (it is for me, but as you will see my
<br>>> analysis is skewed and biased below),
<br>>> but since I need to defend it in front of non-tech people, thought of
<br>>> fishing for opinions/experiences
<br>>>
<br>>> Strict validation:
<br>>> + fail fast
<br>>> any integration mishaps will surface asap, and the API will give
<br>>> descriptive errors for totally unknown or misspelled or mistyped properties
<br>>> (eg. unknown field <adres>, maybe <address>? or post_letter_at must be a
<br>>> timestamp, not a ISO string, etc)
<br>>> + inherent memory optimization
<br>>> if there is more data being sent than you actually know how to process,
<br>>> you will free up memory instantly by throwing an error. That gets even worse
<br>>> if you work with functional programming and you pass contexts around, which
<br>>> may care useless data around.
<br>>> + inherent clean client-server contract
<br>>> server says "send me something that i know how to process, and i will do
<br>>> what you (client) expect me to do"
<br>>>
<br>>> Loose validation:
<br>>> 0 (a fake impression that) integration is smoother
<br>>> since sending unknown properties still allows for successful API requests
<br>>> 0 (a fake impression that) you will get more useful data now
<br>>> just that you don't know what to do with it, other than store it,
<br>>> but that in the future you will get the chance to analyze it one way or
<br>>> the other
<br>>> + memory optimization is still possible
<br>>> if you clean up the request data and only keep data that you know how to
<br>>> process
<br>>> - fuzzy client-server contract
<br>>> server says "send me something, and i will pick what i want from it, and
<br>>> do something that you might or might not expect me to do" eg. sell car X to
<br>>> _persson_ Y, server doesn't understand persson, but only person, but it has
<br>>> the feature to simply sell the car to nobody (ie. put the car on the market
<br>>> for sale), server responds 200 OK and it is up to the client to fix the mess
<br>>>
<br>>> thank you for your time.
<br>>>
<br>>> --
<br>>> You received this message because you are subscribed to the Google Groups
<br>>> "API Craft" group.
<br>>> To unsubscribe from this group, send email to
<br>>> <a href="javascript:" target="_blank" gdf-obfuscated-mailto="O5ZXcGCJmcsJ">api-craft+...@<wbr>googlegroups.com</a>.
<br>>> Visit this group at <a href="http://groups.google.com/group/api-craft?hl=en" target="_blank">http://groups.google.com/<wbr>group/api-craft?hl=en</a>.
<br>>>
<br>>>
<br>>
<br>> --
<br>> You received this message because you are subscribed to the Google Groups
<br>> "API Craft" group.
<br>> To unsubscribe from this group, send email to
<br>> <a href="javascript:" target="_blank" gdf-obfuscated-mailto="O5ZXcGCJmcsJ">api-craft+...@<wbr>googlegroups.com</a>.
<br>> Visit this group at <a href="http://groups.google.com/group/api-craft?hl=en" target="_blank">http://groups.google.com/<wbr>group/api-craft?hl=en</a>.
<br>>
<br>>
<br>
<br>
<br>
<br>--
<br>Mike
<br>
<br><a href="http://twitter.com/mikekelly85" target="_blank">http://twitter.com/mikekelly85</a>
<br><a href="http://github.com/mikekelly" target="_blank">http://github.com/mikekelly</a>
<br><a href="http://linkedin.com/in/mikekelly123" target="_blank">http://linkedin.com/in/<wbr>mikekelly123</a>
<br></blockquote>
------=_Part_377_31796067.1348673337654--
------=_Part_376_6492369.1348673337654--
Message from discussion validation
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |