Live data from Hacker News

How APIs should be: Drop in keys, running in 1 minute

blog.singly.com

1–10 of 15 posts

Re: How APIs should be: Drop in keys, running in 1 minute

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

Re: How APIs should be: Drop in keys, running in 1 minute

#4
post #2

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…

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.

Re: How APIs should be: Drop in keys, running in 1 minute

#5
post #3

I now know how I like Web APIs to work: Give me the URL and let me go at it with cURL and some scripts to parse the your JSON. [Been using the Salesforce REST API recently, and apart from the process of getting your OAuth token, it's really rather good].

Yes, I was rather pleasantly surprised with the Pivotaltracker API. I managed to get it integrated in our hour registration within 30 minutes.

Check; https://www.pivotaltracker.com/help/api

All calls have ready cURL examples you can copy/paste and try. Prototyping is fast.

And no OAuth. OAuth could be good if it were standardized (and thus would work with a single library without any extra tinkering); it's horrible all over the place. I understand this fanatical obsession with security and such, but just make me login and get a token back.

Anyway; Hooray for Pivotal! (Again)

Re: How APIs should be: Drop in keys, running in 1 minute

#6
post #4
post #2

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…

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.

Exactly! We are Yahoo pipes on steroids.

Re: How APIs should be: Drop in keys, running in 1 minute

#8
post #2

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…

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

Re: How APIs should be: Drop in keys, running in 1 minute

#9
Apropos of nothing: if one is making decisions based on estimates of probable conversion rates, my ballpark for "web page visitor -> makes at least one API request" would be closer to 1/100th of 2% than to 2%. You're probably better off going for an intermediate conversion (cough get their email cough) and then selling them into using the API over time, since this is a thing that the best prospects won't exactly do on a lark.

(I am unsure of whether I like the make-a-play-in-the-browser-utility suggestion from the perspective of the business. I have never work directly on that question for a client, so I don't have even anecdata for y'all on this, but the developer in me says "That's a great idea! That way I don't have to do any work to kick the tires." and the marketer in me says "If we sold 'tire kicking' that would be wonderful now wouldn't it")

Re: How APIs should be: Drop in keys, running in 1 minute

#10
post #8
post #2

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…

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

this seems like pretty standard REST
Post reply on HN