<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 20, 2014 at 8:45 PM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jan 20, 2014 at 3:24 PM, Scott Griepentrog<br>
<<a href="mailto:sgriepentrog@digium.com">sgriepentrog@digium.com</a>> wrote:<br>
><br>
> While looking at <a href="https://issues.asterisk.org/jira/browse/ASTERISK-23125" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-23125</a> it is clear to me that we need standard rules for case on all ARI URI's. To date, the convention has been mostly lower case, which is nominal for REST API's. However, the common use of PJSIP in caps has resulted in some inconsistencies:<br>
><br>
> <a href="http://127.0.0.1:8088/ari/endpoints/PJSIP" target="_blank">127.0.0.1:8088/ari/endpoints/PJSIP</a> => list of PJSIP endpoints<br>
><br>
> <a href="http://127.0.0.1:8088/ari/endpoints/pjsip" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip</a> => same list of PJSIP endpoints<br>
><br>
> <a href="http://127.0.0.1:8088/ari/endpoints/PJSIP/200" target="_blank">127.0.0.1:8088/ari/endpoints/PJSIP/200</a> => details of endpoint 200<br>
><br>
> <a href="http://127.0.0.1:8088/ari/endpoints/pjsip/200" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip/200</a> => Endpoint not found<br>
><br>
> For the purpose of this discussion, let's break the URI into multiple portions, for example:<br>
><br>
> /ari /endpoints /PJSIP /200<br>
> PREFIX PATH TECH RESOURCE<br>
><br>
> And in another example:<br>
><br>
> /ari /channels /channelid /operation<br>
> PREFIX PATH ID OPERATION<br>
><br>
> There could be different capitalization rules applied to each portion. For example, in PJSIP it is completely possible to have one endpoint "foobar" and another "FOOBAR" -- thus we can presume that any resource portion MUST be case sensitive. Similarly, a channel ID must be case sensitive.<br>
><br>
> The TECH portion is currently exhibiting case insensitivity in one case (list of endpoints) and case sensitivity in another (endpoint details).<br>
><br>
> The PATH portion is currently case sensitive (Endpoints or ENDPOINTS results in error).<br>
><br>
> And finally the PREFIX is case insensitive (ArI and aRi both work).<br>
><br>
><br>
> This way leads madness, and I propose we put a stop to it now.<br>
><br>
><br>
> There are many possible variations on how to solve this, but I recommend the following, and invite other suggestions. I believe that having different rules for different portions of the URI will lead to confusion. Since there is already a requirement that identifiers and resources are case sensitive, I recommend standardizing on case sensitive for the entire URI. Other than the TECH name which historically in Asterisk has been CAPS, all portions should be lower case where possible to meet current web API norms. In detail:<br>
><br>
> PREFIX: case sensitive, always lower case<br>
><br>
> PATH: case sensitive, always lower case<br>
><br>
> TECH: case sensitive, case determined by actual technology name, convention is all UPPERCASE<br>
><br>
> RESOURCE: case sensitive, must match actual configured value.<br>
><br>
> ID: case sensitive, must match actual identifier<br>
><br>
> OPERATION: case sensitive, always lower case<br>
><br>
> This recommendation is compatible with the vast majority of existing documentation, and will require very little code change to implement.<br>
><br>
><br>
> tl;dr: make TECH the only uppercase URI portion by convention, everything else is lower case except IDs and resource names, and EVERYTHING is case sensitive.<br>
><br>
</div></div>Personally, I prefer everything to be lower case when possible. So,<br>
things like TECH, if PJSIP, pjsip, PjSiP, are all valid inside<br>
asterisk, lets round down to pjsip. However, if ENDPOINT is case<br>
sensitive in Asterisk, then expect the end user to enter it as such.<br>
<br>
So using your example above:<br>
<br>
<a href="http://127.0.0.1:8088/ari/endpoints/pjsip/200" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip/200</a><br>
<br>
or<br>
<br>
<a href="http://127.0.0.1:8088/ari/endpoints/pjsip/FooBar" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip/FooBar</a><br>
<br>
or<br>
<br>
<a href="http://127.0.0.1:8088/ari/endpoints/pjsip/foobar" target="_blank">127.0.0.1:8088/ari/endpoints/pjsip/foobar</a><br>
<br>
All return different endpoints.<br>
<br>
Additionally, have we even considered embedding the actually resource<br>
URL when we list an object in the return result? Then Asterisk can<br>
tell the user exactly how to get a specific item in the list.<br>
<br>
For example, we create a links: [] object, that would list the actual<br>
URI for said item.<br>
<br>
--<br>
Paul Belanger | PolyBeacon, Inc.<br>
Jabber: <a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a> | IRC: pabelanger (Freenode)<br>
Github: <a href="https://github.com/pabelanger" target="_blank">https://github.com/pabelanger</a> | Twitter: <a href="https://twitter.com/pabelanger" target="_blank">https://twitter.com/pabelanger</a><br>
<br>
_______________________________________________<br>
asterisk-app-dev mailing list<br>
<a href="mailto:asterisk-app-dev@lists.digium.com">asterisk-app-dev@lists.digium.com</a><br>
<a href="http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev" target="_blank">http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev</a></blockquote><div><br></div><div>+1 to everything Paul said </div>
</div><br></div></div>