search

waldoj / frostline

A dataset, API, and parser for USDA plant hardiness zones.
https://phzmapi.org/
MIT License
149 stars 25 forks source link

API changed #7

Closed harpster604 closed 8 years ago

harpster604 commented 8 years ago

Looks like the API has changed and now nested in "/secure/". The old API link throws a 404 not found.

http://planthardiness.ars.usda.gov/PHZMWeb/secure/ZipProxy.ashx?Zipcode=98230

and it doesn't work with the script because it returns

captcha#show

unless a captcha is entered on the USDA site, in which case it lets you use it 5 times, then returns the above message again.

waldoj commented 8 years ago

Argh. So the USDA is actively working on preventing us from using their API.

waves to the USDA

usda

I'm 90% sure that there's not going to be a way around this. (Doing anything to break the CAPTCHA would be DMCA-prohibited circumvention, I assume.)

harpster604 commented 8 years ago

@waldoj Is there anywhere I can get a recent full database file? I should have ran the script sooner but I guess now it's too late. All of the links that I found pointing to the file are deadlinks :(

waldoj commented 8 years ago

I'm afraid not. I dropped the storage of data from this repository, out of an abundance of caution. This is exactly why it's important to mirror government data.

waldoj commented 8 years ago

There's a way around it! Yay for my weasely 10% wiggle-room. I'm closing this issue for that one.

waldoj commented 8 years ago

Well, the API itself returns captcha#show instead of data. That seems like an API problem. :)

webmaven commented 8 years ago

@ajturner, I concur with @waldoj. The fact that the API is returning something other than a HTTP code here (offhand, 401 seems likely to be the most appropriate) to communicate a constraint (or actually, cause the front end to communicate a constraint) to the user, is a rather bad API design in part because of the way it couples the API to a particular client implementation. And besides using an appropriate HTTP code, a response with data should ideally also include a count for how many more requests are left before re-authenticating as a human is required.

The further issue of requiring a CAPTCHA in the first place for every X requests where X is so low (rather than, say, being triggered by exceeding some reasonable requests/minute rate limitation) is a also an API usability issue, one that degrades the developer experience considerably, as well as being a UI usability issue by making the user prove they are a human so often.

But then, the whole point of inserting the CAPTCHA was to reduce the usability of the API and the page, wasn't it? :grimacing: :no_good: