[zubairov]

Good points are covered in this blog post, however what if we would push it even further?

Why would people need to download a package? Why would anybody need to learn a programming language you package designed for (or assume you distribute packages for many programming language)?

When using APIs for integration or mashups, especially in business world, person who know how solution should looks like may not have time to code. So we at http://elastic.io think API could be via visual designer.

We believe it's also a way to make API usage _simpler_ for enduser, even the one who can not, or have no time to code.

[jmathai]

We implemented something similar for The OpenPhoto Project where every URL a user visits is a visual representation of an API endpoint.

My site, for example, is at http://jmathai.openphoto.me/photos/list. You can add ".json" to the end to see the JSON representation of that page. http://jmathai.openphoto.me/photos/list.json. The same rule applies across the site.

We wrote about it a while back.

http://blog.theopenphotoproject.org/post/8462620991/clean-ur...

[zht]

this seems like pretty standard REST

[jmathai]

It's REST-ish. But the highlight I was hinting at is making the API itself be more discoverable. We did it by mapping the API directly to the web UI such that html just becomes the default format type of the API.

[kristjan]

Good call. Maybe it was misworded in the post, but the packages available for download are fully functional app skeletons that consume the API and are ready for you to build on. The API itself is just JSON over HTTP.

Making an API accessible without code is an admirable goal. Reminds me of Yahoo Pipes and the application-via-visual-blocks frameworks.

[zubairov]

Exactly! We are Yahoo pipes on steroids.