This is nice if considered a programming exercise but it's actually pretty useless for real world use.
This data is static, that is it very rarely changes. The whole dataset is also very tiny. It's just better to store this data in-house and don't provide unnecessary point of potential failure by using an external service.
An idea on how to make it more useful is to provide downloadable data dump in several formats suited for immediate import into various data stores. An extra addition might be modules for popular frameworks providing access to this (local) data in all the ways your web service does.
I'm not trying to diss, just trying to find some value for real world usage. The service is neat otherwise.
>> It's just better to store this data in-house and don't provide unnecessary point of potential failure by using an external service.
Isn't this the point of rfc2616 sec13? I haven't looked, but if there are etags etc then I think a computer is better than a human at looking for new data, no?
totally get your point. although there are cases when using an external service is actually more convenient. maybe riskier but still convenient. thanks.
The callingcode endpoint only returns one result even when there is more than one that qualifies, as is the case with 1 and USA and Canada (and others that are part of the North American Numbering Plan)
Just wanted to add some thoughts on how one could try to make this RESTful. First, if it were me, I'd pick a media type that can express hyperlinks in JSON (since JSON knows nothing about hyperlinks), maybe something like HAL [1]. Next, I would define my link relations for this API, which in this case would be a collection of countries and the countries themselves (so at least two different types of resources).
After creating the representations of each of these resources, I would then create URI templates in my root response (I guess found at /rest) that allow for the searching aspect that this site is providing, which would be something like:
I may build on to this to provide other resources, like a collection of capitals, each with a link to "/rest/capital/{capital_city}", or a resource of currencies, linking to "/rest/currency/{currency}".
The goal of all of this would be to tell the client how to find resources rather than having that hard-coded into the client. These are just some first steps toward being RESTful, and there are lots of different directions you could take this and still be RESTful.
Neither is more or less RESTful than the other. The media type and link relations express to the client what resource is being returned, not the URL itself.
This data is static, that is it very rarely changes. The whole dataset is also very tiny. It's just better to store this data in-house and don't provide unnecessary point of potential failure by using an external service.
An idea on how to make it more useful is to provide downloadable data dump in several formats suited for immediate import into various data stores. An extra addition might be modules for popular frameworks providing access to this (local) data in all the ways your web service does.
I'm not trying to diss, just trying to find some value for real world usage. The service is neat otherwise.