4 ms·

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 t

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

kristjan 14y ago
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 14y ago
  Exactly! We are Yahoo pipes on steroids.
jmathai 14y ago
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 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 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-urls-that-your-users-should-be-able-to-guess http://blog.theopenphotoproject.org/post/8462620991/clean-ur...
- zht 14y ago
  this seems like pretty standard REST
  - jmathai 14y ago
    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 14y ago

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 14y ago
Exactly! We are Yahoo pipes on steroids.

jmathai 14y ago

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 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 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-urls-that-your-users-should-be-able-to-guess http://blog.theopenphotoproject.org/post/8462620991/clean-ur...

zht 14y ago
this seems like pretty standard REST
- jmathai 14y ago
  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.