> As a website owner, you want to ensure you serve humans, and as a web service provider you want programmatic access to your content to go through your API ins

> As a website owner, you want to ensure you serve humans, and as a web service provider you want programmatic access to your content to go through your API instead of being scraped through your heavier and less stable web interface. I'm not sure as a website owner I want to only serve humans. What happens if someone bookmarks my site with a service like Delicious or Pocket or Pinboard and that site wants to scrape metadata from my site? Poor user can't see the metadata because I have a strange preference for human over robot users. Oh, sure, those sites should get API keys, right? Err, no. Why should someone need to be able to parse arbitrary JSON and have to sign up with an API key for every site they visit? Your web site shouldn't be (significantly) heavier or less stable. In an ideal world, if you followed REST properly, there'd be no real difference between an API and a website: both are just hypermedia representations of the resources you make available. You can put data inside HTML (microformats, RDFa). You can use content negotiation so that you can have the same URLs serving up different content types. Also, by filtering programmatic access, you'll piss off a lot of geeks who use stuff like PhantomJS to automate boring tedious shit that your website probably makes us do. I have little scripts that do stuff like automatically download invoices from suppliers for accounting purposes. All in order to prevent a security threat that shouldn't exist because you shouldn't have to rely on filtering particular browser types for your site to remain secure.