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

[Scott Griepentrog]

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>