[VoiceOps] local calling database

[Troy Davis]

On Mon, Sep 13, 2010 at 8:44 AM, John Todd <jtodd at loligo.com> wrote:


> Troy -
>  Excellent, and very useful!  However:
>

Thanks!


>
>  a) I tried with just six digits, and it failed.  ("We're sorry, but
> something went wrong.")
>

Good question.  The /10digit path was a nod to convenience for people just
starting to use it. The 6 and 7 digit paths are /NPA/NAA and /NPA/NXX/Y, on
the grounds that it makes the hierarchy obvious -- that is, if you see
/2066831, it's not obvious that /206683 is also a URL, but /206/683/1 makes
that clear -- and because API clients performing NPA+NXX queries are likely
to be more advanced.  They're probably doing some parsing or validation
anyway, so expecting split input seemed reasonable.  We made sure that
/NPA/NXX/YYYY works so that hierarchy is complete.

http://help.cloudvox.com/faqs/digits/digits-phone-number-location-lookup-apihas
docs for the paths that do exist.


>  b) You might consider insisting on fully-qualified e.164 numbers,
> including the country code, or at least understanding a "+" denotes a fully
> qualified e.164 number or leading portion of an e.164 number.  Why?  Because
> there are some really interesting databases you might add to this that work
> outside of NANPA, and you don't want to dig a hole you can't get out of with
> users becoming familiar with a particular type of URL call.
>
>  I tried "+12066831234" and it worked great.  Fantastic!  But then I tried
> "+22066831234" and that uh... worked as well.  And then I tried
> "+442066831234" and that... astonishingly... worked TOO!  So clearly, there
> is something a bit odd in that API parser.
>

Yeah, it's very NANPA-centric right now.  We wanted to pick a set of
information we knew would be complete enough to be useful.  I'd love (and
have plans to) add other data, and I think if/when there's other data, it
would accept /E164 for a specific number and /countrycode/regioncode to
browse.

We're using Rails' request router with a couple regexes, so the parser can
almost certainly be confused if you try (though I believe it works for all
the documented cases).  I'm okay with garbage in, garbage out ;-)

Canada will probably be next up since we have the data and it's easy to
parse.  If anyone has pointers to downloadable CSVs for another country and
would consume the service if that country was added, email me offlist.

Troy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20100913/10f0f932/attachment.html>