Good luck... Love the design.<p>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.<p>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?<p>> TCP dumps, Wireshark, installing local HTTP proxies… Not fun.<p>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.
Is is just me, or are their docs kind of yuck/hard to read?<p><a href="http://docs.timdorr.apiary.io/#vehiclecommands" rel="nofollow">http://docs.timdorr.apiary.io/#vehiclecommands</a><p>My biggest problem: way too much visual emphasis on 'GET' part and not enough on the actual URL. That has way more priority, to me.
I'm bit biased. I'm running a marketplace for APIs since 2010 but defining itself like the largest API Hub is a bit false. It's doesn't matter how many APIs you have, since the majority of those are "fake, draft, etc" not real working APIs, they are mocks. What makes you substantial is: 1) # of API transactions passing via you "apps in production running on you", 2) # of total active developers in your community "hub = consumers + providers not just one side" 3) money "enterprise customers, revenue, subscriptions, etc"<p>Real activity, not mocks.
Congrats on the funding. However, I'm not sure what Apiary does, or why I'd use it. Could someone help me? Is it an API mocking tool? A documentation tool? Both? Can I use it next to my existing source tree?
Does anyone know how this compares to wordnik's Swagger [1] ? I think Swagger is incredible, would love to see more API tools which promote good habits and make it easy to be beautiful.<p>[1] <a href="https://developers.helloreverb.com/swagger/" rel="nofollow">https://developers.helloreverb.com/swagger/</a>
The mock server generated out of a minimal markdown-like syntax seems pretty cool.<p>As far as the docs themselves I think I prefer the design of something like Swagger (<a href="https://developers.helloreverb.com/swagger/" rel="nofollow">https://developers.helloreverb.com/swagger/</a>).
In related news nobody upvoted, rich-client focused web APIs may be becoming an endangered species: <a href="https://news.ycombinator.com/item?id=6392022" rel="nofollow">https://news.ycombinator.com/item?id=6392022</a>
This is awesome.. And Immediately runs into the problem of being purely SaaS. I can't use this for APIs that I develop internally within my 'Big Company'.<p>If I could host this somewhere behind my firewall, then something like this becomes a no brainer. But making me try to convince my security team to send all of my API calls and design to an external service puts a huge barrier to entry for me politically.<p>I love the idea to the point that I started searching for something similar that I could host inside. Even Github lets me host a copy of their software somewhere nice and corporate safe.<p>I wish more service providers would offer more than just 'pure SaaS' to allow for easier adoption by corporate customers.
Awesome. I really like the design and simplicity. From the example on <a href="http://apiary.io/how-it-works" rel="nofollow">http://apiary.io/how-it-works</a> how are language bindings generated? How do you know the schema of a message?<p>I've actually been working on something similar, but more focused on library generation and like a "npm for APIs", e.g. reusable schemas. Instead of markdown I'm using something more akin to Google's Discovery Document (<a href="https://developers.google.com/discovery/v1/reference/apis#resource" rel="nofollow">https://developers.google.com/discovery/v1/reference/apis#re...</a>).
A number of related solutions for web services integration:<p><a href="http://programmers.stackexchange.com/a/181593/16090" rel="nofollow">http://programmers.stackexchange.com/a/181593/16090</a>