11–20 of 37 posts
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.
[Disclosure: I work at Singly]
I'm not very familiar with them but check out https://www.mashape.com/
As far as security is concerned, you probably don't want user authentication like a username/password combo to be passed with the requests, but rather acquire an oauth token that expires after a certain period of time and have specific rights within a scope to read-only vs write based on that token. One question with concurrent API queries is how would you handle the race condition? Say I query 3 APIs at the same tim…
"One thing I haven't found, however, is one API that lets the skilled developer manipulate and search multiple APIs at once." 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?
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.
"One thing I haven't found, however, is one API that lets the skilled developer manipulate and search multiple APIs at once." There is one, it is called "the internet"
Yes, but HTML+JS+CSS has helped turn HTTP into an application environment, and not the content transport protocol it once was. 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 acce…
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...