Review my startup idea: One API to rule them all.
27 points| levicampbell | 13 years ago | reply
A few questions. * I'm currently using a SQL style language to make adding more advanced features easier on my part, but if someone has a better idea, I'm all ears. * If a service requires user authentication (i.e. Twitter), my current plan has users passing in auth data in the body of a POST request, is this secure or is there a better way to do this?
If someone has any comments, questions, or ideas, please let me know. Thank you for your time and consideration.
[+] [-] eclipxe|13 years ago|reply
There is one, it is called "the internet"
[+] [-] evv|13 years ago|reply
REST is popular now, but it's not a real protocol. There's SOAP, but nobody really cares or wants to use it anymore.
The web is undoubtedly missing a social content protocol. I predict one will gain popularity in the next couple of years.
EDIT tldr: Until my blog has an open and commonly accepted way to 'friend' or 'follow' your blog, how can we possibly say that we are "done" with online social protocols?
[+] [-] kristjan|13 years ago|reply
[Disclosure: I work at Singly]
[+] [-] mehdim|13 years ago|reply
http://Zapier.com, http://IFTTT.com, http://rules.io and http://elastic.io, http://ritc.io , http://kynetx.com/
or more focused on developers like :
http://temboo.com, http://singly.com, http://webscript.io, http://cloudsnap.com, http://script.google.com , http://webshell.io
What would be your main paradigm and what do you want to bring to the ecosystem?
Disclosure : I work for webshell.io and lol to see that your post make reactions of lots of API of APIs company (Singly, Cloudsnap, Ritc.io)
If some one in this page wants to reach us for open discussion for making the web programmable in an easier way team[at]webshell.io
[+] [-] kevindykes|13 years ago|reply
[+] [-] slajax|13 years ago|reply
[+] [-] styts|13 years ago|reply
[+] [-] kenneth_reitz|13 years ago|reply
[+] [-] aioprisan|13 years ago|reply
One question with concurrent API queries is how would you handle the race condition? Say I query 3 APIs at the same time, will I have to wait until the slowest one returns the results to get all results? Will it instead push results to a pre-determined results URL?
What are some cases when you would query multiple APIs and want the results at the same time? Why not just wait for each result, parse it myself, then pass some piece of that computed result to the next query, and so on? What would be amazing would be a universal API processor that can do some of this API to API call parsing and processing in the backend, store all credentials, and just get the final results of a long chain of API calls. Now that's something that would make developers' lives easier and I'd pay money for..
[+] [-] Gobitron|13 years ago|reply
[+] [-] thekevinjones|13 years ago|reply
Making the process easier is a huge need right now. There are a lot of apps, and it's all becoming more separated. People want to integrate, and it's a pain in the ass to integrate quickly and cleanly.
EmergentOne and Apigee are helping people create standard API's.
Zapier and IFTTT are giving you a UI to meld them together.
Cloudsnap, Singly, and Webshell are all doing what you're describing, each with a different target of apps. Singly and Webshell are seemingly more social, whereas Cloudsnap is more related to business apps.
And of course, YQL, which has been around a long time.
--
Disclosure: I'm a designer for Cloudsnap, and above is my opinion and not necessarily the views of the company.
[+] [-] benologist|13 years ago|reply
https://www.mashape.com/
[+] [-] polemic|13 years ago|reply
[+] [-] zalambar|13 years ago|reply
What use case do you believe it serves (who would use it, what existing behavior would it replace)?
If you're going to call this a "startup" then what is the business plan beyond some set of technical features which may or may not be feasible?
[+] [-] lr|13 years ago|reply
http://www.simplecloud.info/
It started as Simple Cloud Identity Management, but once it got to IETF, it was changed to "System for Cross-domain Identity Management". This initiative has been backed by Google, Ping Identity, Salesforce, Cisco, SailPoint, UnboundID, and others. You can see some of these names on one of the RFCs:
http://tools.ietf.org/html/draft-ietf-scim-core-schema-00
This API is just for identity management, and it has taken years to get to this point. I think it would take many more to get to a common API for everything else.
[+] [-] mehdim|13 years ago|reply
Either is the standard, either it the the most adapted product/company (not necesseraly technologically) which wins the pot. This is technology AND business model, user community, strategic partnerships which will make an API to rule them all a defacto standard which will lead the programmable web. But you're right that IETF standards for APIs may be so long that I consider it is not possible untill decades !(or a leader which will open and free its winning standart to all only)
[+] [-] misframer|13 years ago|reply
[+] [-] thingylab|13 years ago|reply
It seems to me that you would mostly act as a proxy between a user and a service, which really doesn't sound too useful unless one actually needs to access dozens of APIs (which doesn't seem to be something that happens often).
Or is your idea really an aggregator (e.g. "find images using such and such keywords" and it returns results from flickr, 500px, ...) ?
[+] [-] rckrd|13 years ago|reply
Even though this seems to try to solve that problem, I think it obfuscates whats usable more than the internet does in simply just searching for the API.
[+] [-] web007|13 years ago|reply
Auth should be linked separately from the individual requests if you can. It would be a lot better to auth against $yourService, and $yourService has the cached / OAuth'd credentials for $otherService and handles the auth dance / request signing / whatnot.
[+] [-] mehdim|13 years ago|reply
[+] [-] mtraven|13 years ago|reply
[+] [-] mehdim|13 years ago|reply
[+] [-] roycehaynes|13 years ago|reply
[+] [-] ville|13 years ago|reply