i'm fluent in javascript as well as klingon.
hello world. my name is Ryan Alexander Boyles. often, it's pronounced the RAB. i'm into declarative living. i am a connector. this is my life-stream / tumblr / blog. call it what you will. find my sxsw posts.
any questions, ask me anything! btw, here is a standard disclaimer.
Catching Elephant is a theme by Andy Taylor
REST is a term coined by Roy Fielding in his Ph.D dissertation, and it denotes an architectural style for Web services and applications that manipulate media content. It can be considered a set of best practices for using the HTTP specification (RFC 2616) as an application layer protocol. There are no standards or APIs, and the primary ingredients are found in all HTTP-based Web applications and services. A good analogy for REST is “object-oriented” Web programming in which the resource specified by the URI is the object, the method is specified by the HTTP verb, and the parameters are specified by the HTTP headers, such as Accept or the URI query.
Migrating to the Twitter Streaming API: A Primer
by Eric Marcoullier « Gnip – Delivering the Web’s Data
Some context:
Long, long ago, in a galaxy far, far away, Twitter provided a firehose of data to a few of partners and the world was happy. These startups were awash in real-time data and they got spoiled, some might say, by the embarrassment of riches that came through the real-time feed. Over time, numerous factors caused Twitter to cease offering the firehose. There was much wailing and gnashing of teeth on that day, I can tell you!
At roughly the same time, Twitter bought real-time search company Summize and began offering to everyone access to what is now known as the Search API. Unlike Twitter’s existing REST API, which was based around usernames, the Search API enabled companies to query for recent data about a specific keyword. Because of the nature of polling, companies had to contend with latency (the time between when someone performs an action and when an API consumer learns about it) and Twitter had to deal with a constantly-growing number of developers connected to an inherently inefficient interface.
IBM developerWorks : Blogs : Web 2.0 and Middleware
By the way, this is exactly the model that WebSphere sMash (Project Zero) has for applications on the server. Every application runs in its own process, and you do not deploy an app to a server, you just run the app, which is the server.
The google (Chrome) browser model matches what we have been doing with WebSphere sMash and Project Zero on the server. I can definitely see an architecture where applications running on the desktop call applications in the cloud that service them (or are bound to them as shown in the figure below).
