> Your developers suck if they can't debug the freakin' API they are supposed to be building. You're doing it very very wrong if you need wireshark or HTTP proxies to debug your code.
And what if I am using a library to connect to a 3rd party service (i.e. github) and I'd like to debug my API calls?
There are so many scenarios for debugging APIs that don't fall into the "I control both ends, so I should be able to see everything." camp. SDKs, poorly implemented or documented APIs controlled by a 3rd party (frequently even across a company where the people producing are far removed from the consumers), differing environments (works locally, not in staging, etc), UI-less machine-to-machine interactions (debugging webhooks is especially annoying) and many more.
If you check my bio, you'll see my bias toward these problems. But there are a lot more of them and a lot more variants than you give credit to.
You're right about end-to-end control. But, my point is I don't see the future of web development consisting of 3rd party PaaS services.
Are you saying you'd pay for Apiary to debug HTTP requests? How did you solve this issue before? There are many open source libraries to do exactly this.
I just can't imagine a future where development tooling consists of subscription to a bunch of disparate services.
> I just can't imagine a future where development tooling consists of subscription to a bunch of disparate services.
New Relic, Exceptional/Airbrake, SendGrid/Mandrill, Codeship/CircleCI, Github, etc. You can do all of those on your own, but we pay for all these services quite often. Apiary may not be your cup of tea, but I think people will pay for it.
ah... I see you're the founder of Runscope now. I would be more inclined to use something like Runscope where - unlike Apiary - the value proposition is very clear and you're focused on doing one thing and doing it well.
And what if I am using a library to connect to a 3rd party service (i.e. github) and I'd like to debug my API calls?