[asterisk-app-dev] Standardization of Case for ARI URIs

Scott Griepentrog sgriepentrog at digium.com
Tue Jan 21 13:08:15 CST 2014


Okay, so the consensus I'm hearing is to change from case sensitive
throughout to case sensitive only for identifiers and resources, and leave
everything else insensitive and lower case (including technology).


PREFIX: case insensitive

PATH: case insensitive

TECH: case insensitive, case determined by actual technology name,
convention is all UPPERCASE, but either will match

RESOURCE: case sensitive, must match actual configured value.

ID: case sensitive, must match actual identifier

OPERATION: case insensitive


Going forward (all future ARI URIs), the standard then is that all portions
of a URI are case insensitive except where they are identifiers or resource
names where the case matters.


Unless I receive any objections to this plan, I will go ahead and implement
this later (in the coming days) when I get to the originating issue.



On Tue, Jan 21, 2014 at 11:51 AM, Leif Madsen <lmadsen at thinkingphones.com>wrote:

> I agree with Paul here. Lets assume we're working with a standard web
> type interface and not have a preferred uppercase convention just
> because "that's how Asterisk has always done it".
>
> The preference should be for lowercase throughout, except for any
> channel or peer identifiers which need to be case sensitive due to
> naming conventions.
>
> Leif.
>
> -----Original Message-----
> From: Paul Belanger <paul.belanger at polybeacon.com>
> Reply-to: Asterisk Application Development discussion
> <asterisk-app-dev at lists.digium.com>
> To: Asterisk Application Development discussion
> <asterisk-app-dev at lists.digium.com>
> Subject: Re: [asterisk-app-dev] Standardization of Case for ARI URIs
> Date: Mon, 20 Jan 2014 15:45:36 -0500
>
> Personally, I prefer everything to be lower case when possible.  So,
> things like TECH, if PJSIP, pjsip, PjSiP, are all valid inside
> asterisk, lets round down to pjsip.  However, if ENDPOINT is case
> sensitive in Asterisk, then expect the end user to enter it as such.
>
> So using your example above:
>
> 127.0.0.1:8088/ari/endpoints/pjsip/200
>
> or
>
> 127.0.0.1:8088/ari/endpoints/pjsip/FooBar
>
> or
>
> 127.0.0.1:8088/ari/endpoints/pjsip/foobar
>
> All return different endpoints.
>
> Additionally, have we even considered embedding the actually resource
> URL when we list an object in the return result? Then Asterisk can
> tell the user exactly how to get a specific item in the list.
>
> For example, we create a links: [] object, that would list the actual
> URI for said item.
>
>
>
>
> --
> Leif Madsen
> Lead UC Systems Engineer
> c: +1-613-800-7610
> http://thinkingphones.com
>
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>



-- 
[image: Digium logo]
Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
Check us out at: http://digium.com · http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20140121/cc4e485c/attachment.html>


More information about the asterisk-app-dev mailing list