TL,DR:<p>+ Use content negotiation headers instead of explicit content extensions for resources.<p>+ Don't pass auth tokens as part of the URL (you monster).<p>+ Don't have onerous processes for obtaining API keys.<p>+ Web scraping is totally a legit way of providing programmatic access to data.<p>~<p>Sadly, the author is kind of wrong in these cases.<p>First, as I've run into on some of my own projects, specifying desired content type (.html, .csv, .json) in the URL is actually pretty handy. In Rails, for example, you just you a respond-to-format block. This lets clients using dumb web browsers (and you'd be surprised how many of <i>those</i> there are) download easily the type of content they want. Accept headers are useful, but they don't solve everything.<p>Second, I do agree that auth tokens should go in the header--that's just reasonable. If I'm doing something that needs an auth token, I probably am curl'ing, and so I can easily set headers.<p>Third, keys are a necessary evil. They are the least annoying way to track access and handle authorization. That said, it shouldn't be awful to get a hold of one--in our previous startup, api keys were similar to auth tokens, and that worked out fine.<p>Fourth, web-scraping is not a good solution. "Herf derf just have your dev scrape the thing" is cool and all, but if the document is not marked-up in a friendly way, that information can be very brittle. Moreover, you run the risk of having cosmetic changes break scrapers silently. It's far better just to expose a machine-friendly API (which is handy for testing and monitoring <i>anyways</i>) and let your frontend devs do whatever wacky stuff they want in the name of UX.<p>EDIT:<p>I am all for rate-limiting as a basic step where keys do not suffice.<p>As for scraping, the article is a bit weird on this point. The author's insistence on "DONT USE APIS EVER RAWR" and then on "hey, let's use application/json to provide documents under the same paths for machines" is goofy. It's like they don't want you to use an API, except when they do.<p>The wording and phrasing just really gets in the way of the article--had the tone been a bit less hyperbolic, it would've been a decent "This is why I find web APIs frustrating to work with" with examples.<p>EDIT EDIT:<p>The author is a Semantic Web wonk. That explains it.