On Mon, Sep 13, 2010 at 8:44 AM, John Todd <span dir="ltr"><<a href="mailto:jtodd@loligo.com">jtodd@loligo.com</a>></span> wrote:<br><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Troy -</div>
  Excellent, and very useful!  However:<br></blockquote><div><br></div><div>Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
 a) I tried with just six digits, and it failed.  ("We're sorry, but something went wrong.")<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div><a href="http://help.cloudvox.com/faqs/digits/digits-phone-number-location-lookup-api">http://help.cloudvox.com/faqs/digits/digits-phone-number-location-lookup-api</a> has docs for the paths that do exist.  </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
 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.<br>


<br>
  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.<br>

</blockquote><div><br></div><div>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.</div>

<div><br></div><div>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 ;-)</div>

<div><br></div><div>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.</div>

<div><br></div><div>Troy</div><div><br></div></div>