<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.msolistparagraphcxspfirst, li.msolistparagraphcxspfirst, div.msolistparagraphcxspfirst
{mso-style-name:msolistparagraphcxspfirst;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.msolistparagraphcxspmiddle, li.msolistparagraphcxspmiddle, div.msolistparagraphcxspmiddle
{mso-style-name:msolistparagraphcxspmiddle;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.msolistparagraphcxsplast, li.msolistparagraphcxsplast, div.msolistparagraphcxsplast
{mso-style-name:msolistparagraphcxsplast;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I tend to agree. The specific response code is a contract from the API that in condition X, it will return exactly Y. I would give a nod to what Daryl is saying
that if the response codes were externalized and vendor configurable you could make somewhat of an argument to generalize the check, however, at that point I would think that the specific configuration that the vendor has in place should still be validated
with the exact codes. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We have had issues as well where a call may return say a 401 instead of a 404 which would have caused a downstream issue. A generic check for a startswith(‘4’)
would have let that through.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--Sam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Daryl Walleck [mailto:daryl.walleck@RACKSPACE.COM]
<br>
<b>Sent:</b> Wednesday, January 30, 2013 4:55 PM<br>
<b>To:</b> openstack-qa@lists.openstack.org; All Things QA.<br>
<b>Subject:</b> Re: [openstack-qa] Return codes for OpenStack APIs<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">I'm a proponent of checking the exact code. To me, its part of the API contract. From a practical point, it has also helped our automated tests catch bugs that nearly slipped by. One case
I an remember is when some various POSTs started returning a 200 code as opposed to a 202, with the end result being that the requests responded to with a 200 actually were not processed. The only reason I could think of to generalize response code checking
would be if it the response codes were ever vendor configurable. <o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">Daryl<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""> <o:p></o:p></span></p>
</div>
</div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:0in 0in 0in 0in">
<p class="MsoNormal"><strong><span style="font-family:"Calibri","sans-serif"">From:</span></strong><span style="font-family:"Calibri","sans-serif""> David Kranz<br>
<strong><span style="font-family:"Calibri","sans-serif"">Sent:</span></strong> January 30, 2013 4:08 PM<br>
<strong><span style="font-family:"Calibri","sans-serif"">To:</span></strong> <a href="mailto:openstack-qa@lists.openstack.org">openstack-qa@lists.openstack.org</a><br>
<strong><span style="font-family:"Calibri","sans-serif"">Subject:</span></strong> [openstack-qa] Return codes for OpenStack APIs<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif""> <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif"">There have been recent submissions to Tempest with code like:<br>
<br>
self.assertTrue(resp['status'].startswith('2'))<br>
<br>
It had been the consensus that we should be checking for actual status <br>
codes. Some projects document the return<br>
codes and others don't. This example was from a call to keystone to list <br>
services and the result is not documented but the list tenants<br>
calls says it could return 200 or 203. There should be a statement from <br>
each project about whether it considers the return code to be part of <br>
the spec.<br>
Ideally this would be uniform across projects but it is not. Users of <br>
the API really need to be able to know this. Any comments?<br>
<br>
-David<br>
<br>
_______________________________________________<br>
openstack-qa mailing list<br>
<a href="mailto:openstack-qa@lists.openstack.org">openstack-qa@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-qa</a><o:p></o:p></span></p>
</div>
</div>
</body>
</html>