Show HN: APIBoard, Interactive API Documentation with JS-Powered Workflows | Hacker News Reader

Show HN: APIBoard, Interactive API Documentation with JS-Powered Workflows

apiboard.us

15 pointsrevetkn9 comments

The basic idea is we wanted a hosted Postman which allows you to wire your endpoints together "lego-style" into workflows (step 1 is authenticate, step 2 is fetch a list of users, step 3 is update the first user in the list). You can then shoot someone a URL and they can hit the "play" button and the API calls execute before their eyes. Some other notable features we've added are team support, versioning, and dependency tracking.

The drawback of most hosted services like this is you can't see things on private networks, like localhost or a corporate intranet. We have an OS X native app to circumvent this and a Windows version is coming soon.

We'll try to answer any questions you might have, thanks for checking it out!

I am interested in the concept, however I feel like the mix of GUI and code editors is too complex. I'd rather see it all in a code editor without the GUI.

Thanks for your feedback - getting the UI right is one of the big challenges for us given the complexity of the system. We've been experimenting internally with different approaches, one of them being a per-user preference "raw" mode that works as you described.

I've been playing with this on and off for a few weeks. My shop has their own REST development and review process. So I've been using it as an educational tool for devs new to REST, fits the bill better than swagger or postman.

The landing page is so messed up on safari mobile that I can't even read it.

Whoops, sorry, our fault - should be fixed now. The viewport meta tag was unintentionally locking scaling and initial zoom level.

I doubt that it was unintentional.

It's an old fix to what I perceive as a non-problem [0]. When a user turns their iPhone to view it on Landscape - the site won't resize without that viewport meta tag being there.

Not sure if it's been fixed. Even if it hasn't, I question the amount of people who browse on their phones in Landscape.

[0] http://webdesignerwall.com/tutorials/iphone-safari-viewport-...

I'm running under the assumption that you might not be the dev and that the dev may have added it there intentionally to fix the landscape bug. This post has the wrong tone without it being read more explanatory, so I felt this clarification necessary.

"Unintentional" as in "pretty sure it was an old copy-paste from another app and we forgot to take that line out" :) I don't like the scroll locking myself, even when applied "correctly".

Hopefully the site is at least navigable now on Mobile Safari. We will be revisiting the mobile experience soon. Had not been focusing much on it since the app is form-heavy and doesn't lend itself well to mobile, but for the marketing site we certainly need to focus on it more...first impressions are very important, and a broken page is not a good one! Thanks for your feedback.

Good to hear! I've seen enough cases of devs not bothering to explain why something is the way it is to marketers/management (it can be a hassle) and simply remove or add what is asked for. Wanted to make sure it was known why that was there.

Cheers!

Reply on news.ycombinator.com