<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>This is a little sticky and I can definitely see how these could be read either way. <br>
<br>
For what it's worth, my go-to resource for these things, <a href="https://http.dev/501" class="x_OWAAutoLink" id="LPlnk518528">
https://http.dev/501</a>, also acknowledges the similarity between the two and includes this blurb:<br>
<br>
<span>A 405 Method Not Allowed status code suggests that the HTTP request cannot be filled and that the
<b>functionality will not be available in the foreseeable future</b>, whereas a 501 Not Implemented status code is used to suggest that it’s
<b>“not yet implemented but will be", or “this is something that you can do, once I am ready for you to do it"</b><b>. </b></span><span style="font-size:12pt">In this situation, the server can optionally supply a Retry-After HTTP header, suggesting a time for
the client to try again.</span><span></span></p>
<div><br>
Reading back-and-forth between the two codes, and your replies, I'm actually starting to prefer 405, if a service isn't going to develop it at all.<br>
<br>
Out of curiosity, to confirm what Pat was saying with it being the default response, I did try a simple POST against our service, and 405 is the default response (for our stack, anyway), which is an advantage.<br>
<div>>>> requests.post("https://mast.stsci.edu/vo-tap/api/v0.1/hsc", json={})</div>
<div><Response [405]></div>
<br>
<span style="font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols; font-size:16px">I appreciate people taking a look, and am glad there is some consensus on the
idea at least. </span>As long as we're consistent with it in the OpenAPI doc going forward, I suppose it doesn't matter much.</div>
<p></p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Mark Taylor <m.b.taylor@bristol.ac.uk><br>
<b>Sent:</b> Friday, November 29, 2024 10:04:41 AM<br>
<b>To:</b> Gregory MANTELET<br>
<b>Cc:</b> Patrick Dowler; Joshua Fraustro; dal@ivoa.net<br>
<b>Subject:</b> Re: Optional OpenAPI Endpoints for TAP 1.2 / User-managed Tables</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">External Email - Use Caution<br>
<br>
On Fri, 29 Nov 2024, Gregory MANTELET via dal wrote:<br>
<br>
> Finally, if we refer to RFC 9110 <<a href=""></a>https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9110__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!0ApzGxXgA2HAdc3IVhcvThbKNytXvCPdpdQRoFsyk04P5CeqMWhaFREq8YtZgs4Y30wITC-0yghkSIR_ryLGKBuhito$ > we<br>
> have the following texts:<br>
<br>
To me, these support use of 405 not 501 in this case.<br>
Joshua's example was use of PUT to /tables.<br>
<br>
> > 15.5.6. 405 Method Not Allowed<br>
> > <<a href=""></a>https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9110*name-405-method-not-allowed__;Iw!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!0ApzGxXgA2HAdc3IVhcvThbKNytXvCPdpdQRoFsyk04P5CeqMWhaFREq8YtZgs4Y30wITC-0yghkSIR_ryLGKBu_DXI$ ><br>
> ><br>
> > The 405 (Method Not Allowed) status code indicates that the method<br>
> > received in the *request-line is known by the origin server but<br>
> > not supported by the target resource.* The origin server MUST<br>
> > generate an Allow header field in a 405 response containing a list<br>
> > of the target resource's currently supported methods.<br>
<br>
In this case PUT is an HTTP method known to the server,<br>
but not supported by the target resource (/tables), so 405 looks correct.<br>
<br>
> > 15.6.2. 501 Not Implemented<br>
> > <<a href=""></a>https://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc9110*status.501__;Iw!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!0ApzGxXgA2HAdc3IVhcvThbKNytXvCPdpdQRoFsyk04P5CeqMWhaFREq8YtZgs4Y30wITC-0yghkSIR_ryLG4KQ8B24$ ><br>
> ><br>
> > The 501 (Not Implemented) status code indicates that the server<br>
> > does not support the functionality required to fulfill the<br>
> > request. This is the appropriate response when *the server does<br>
> > not recognize the request method and is not capable of supporting<br>
> > it for any resource*.<br>
<br>
The server does recognise the HTTP PUT method and may well support it<br>
for other resources, just not /tables, so 501 is not suitable.<br>
<br>
My understanding is that 501 is for an HTTP method that's not<br>
recognised like "FOO" or "DELEET", or perhaps one that's just<br>
not implemented at all by the server.<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
m.b.taylor@bristol.ac.uk <a href="https://urldefense.com/v3/__https://www.star.bristol.ac.uk/mbt/__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!0ApzGxXgA2HAdc3IVhcvThbKNytXvCPdpdQRoFsyk04P5CeqMWhaFREq8YtZgs4Y30wITC-0yghkSIR_ryLGdh0zR8A$">
https://urldefense.com/v3/__https://www.star.bristol.ac.uk/mbt/__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!0ApzGxXgA2HAdc3IVhcvThbKNytXvCPdpdQRoFsyk04P5CeqMWhaFREq8YtZgs4Y30wITC-0yghkSIR_ryLGdh0zR8A$</a><br>
</div>
</span></font>
</body>
</html>