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.
There is one, it is called "the internet"
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?
Do you know why? What makes you think we won't end up at
"There's OneAPItoRuleThemAll, but nobody really cares or wants to use it anymore."
or even at
"There's OneAPItoRuleThemAll, but nobody really cares or wants to use it."
If you cannot answer that, I wouldn't bother working on something like this.
Also, who do you think will be interested in having a common protocol? I think the answer will be "those with little data of their own". Big players do not want you to build tools that work together with 'their' data (clear example: Twitter: open while small, but now closing down its API)
REST+HTTP are not without their issues, but I'd argue they've been successful in allowing numerous heterogeneous applications to speak with each other, in a reliable and standard fashion for many years.
Compared to more complicated protocols such as SOAP, COBRA, DCOM, etc...REST+HTTP is as reliable and ubiquitous today because of its simplicity and generic nature. Adding features and utilities for a particular aspect (i.e. "social") would serve to weaken the protocol, not make it better.
The argument that the HTML+JS+CSS side of things has turned HTTP into an application environment is a bad thing is puzzling. Besides, what is the point of a content transport protocol if not to provide valuable services and use cases on top of it? We have TCP and UDP to push bits around...
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
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..
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.
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)
[Disclosure: I work at Singly]
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.
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?
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, ...) ?
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.
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.
