[dreamdu5t]

Good luck... Love the design.

I can't help but wonder... a person experienced enough to design a REST API wouldn't need or want to rely on said service just to mock it up. I don't see a market for Apiary.

At least in the node.js community, there are lots of tools and projects for mocking REST APIs. Why should I spend the time to sign-up and pay for Apiary, when I could already mock an API in that time instead?

> TCP dumps, Wireshark, installing local HTTP proxies… Not fun.

Developers should be able to debug the freakin' API they are supposed to be building! If someone needs Wireshark or HTTP proxies to debug their code, they are doing it very wrong.

[Almad]

> 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?

[dreamdu5t]

You shouldn't be coding things to be so tightly coupled. You should be able to build and test your API without communicating with a 3rd party.

Sure, there are cases where you have to use a proxy to see a request. I'm surprised there's a market for people who pay for that.

[johns]

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.

[dreamdu5t]

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.

[timdorr]

> 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.

[dreamdu5t]

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.

[AznHisoka]

Web scrapers (there's a lot of them, SeoMoz is even one of them) is a pretty big market for that kind of stuff.

[entropyneur]

Actual Apiary user here. Couldn't care less about the mocking up part. I use it because it's a fantastic tool for writing good-looking API documentation quickly.

[muaddirac]

Also a user. Another big use case is developing for mobile against the planned API while the API is still being developed.

And for systems where the API is provided by several different apps rather than just one, it's nice to have a centralized spec for everyone to conform to. Eventually it's supposed to test your api against your spec, which would be nice.