by Subbu Allamaraju on July 12, 2010
Stephan Schmidt says
I’ve implemented a proof of concept of BigPipe in Java (should run as-is in every servlet container):
See his blog post for the Java servlet class.
Here is the same (or more?) written in Node.js.
var http = require('http');
var sys = require('sys');
var url = require("url");
http.createServer(function(request, response) {
// Write the document
response.writeHead(200, {"Content-Type" : "text/html"});
response.write("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\"" +
" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">");
response.write("<script type=\"text/javascript\">function arrived(id,text) { var b=document.getElementById(id); b.innerHTML = text; }</script>");
response.write("</head><body><div>Progressive Loading");
for(var i = 0; i < 6; i++) {
response.write("<div id='" + i + "'>&;lt;/div>");
}
response.write("</div>");
// Now the snippets
var down = 6;
for (i = 0; i < 6; i++) {
var proxy = http.createClient(2000, "localhost");
var proxyRequest = proxy.request("GET", "/?id=" + i,
{"host" : "localhost"});
proxyRequest.addListener('response', function (proxyResponse) {
--down;
proxyResponse.addListener('data', function(chunk) {
response.write(chunk, 'binary');
});
proxyResponse.addListener('end', function() {
if(down == 0) {
response.end();
}
});
});
proxyRequest.close();
}
response.write("</body></html>");
}).listen(8080);
http.createServer(function(request, response) {
// Some delay upto upto 2 seconds
var delay = Math.round(Math.random() * 2000);
setTimeout(function() {
var params = url.parse(request.url, true);
var id = params.query.id;
response.writeHead(200, {"Content-Type" : "text/html"});
var content = "<span>Content of Module " + id + "</span>";
response.write("<script>" +
"arrived('" + id + "', '" + content + "');" +
"</script>");
response.close();
}, delay);
}).listen(2000);
I've no comments on the technique itself. The basic idea may have been implemented a number of times in different languages. The mileage varies based on the language/environment used.
by Subbu Allamaraju on May 29, 2010
Co-Motion Periscope Torpedo Tandem – Shimano Ultegra – FSA Gossamer 52-39-30 – 12×28 – S+S couplers – Custom built – Fit by Counter Balance Bicycles (University Village, Seattle)
Still learning to maneuver – 103 flat miles in the first week
by Subbu Allamaraju on April 21, 2010
It is a pleasure to read the Facebook Graph API. It avoided many of the traps that web services offered by the other major players in the industry suffer from. Facebook’s API is simple, consistent and inter-connected. It is true to the spirit of the web.
It is simple, because as a developer, I do not have to learn about 10 different web services for each of users, pages, events, groups, applications etc. Having a separate web service for each is like having "end points" – resources that are not connected, each with a different set of conventions. In the Facebook Graph API, there are no end-points.
It is consistent, because all the representations look similar. Each representation has an identifier, a self-link, timestamps, and links to related resources. Apart from these being the ideal characteristics of representations on the web, for a developer, such representations are a pleasure to work with. Facebook just proves that you don’t need to focus heavily on formats like Google Data Protocol or Open Data Protocol to design representations that are consistent.
It is interconnected as every representation is linked to related resources. For instance, an album representation is linked to the profile that posted the album. Each user representation is linked to a collection of groups that the user is member of. This is hypermedia in action. Hypermedia does not have to be complicated – and Facebook just proves it.
I am sure it is possible to nitpick on minor details, but the underlying philosophy cannot be ignored. Finally, support for OAuth 2.0 is the icing on the cake.
by Subbu Allamaraju on April 2, 2010
Now that HTTP PATCH is official, would lack of standard media types and patch formats to describe partial updates to resource hamper its adoption? Most likely not.
The problem with any write request is maintaining integrity of the data in the backend. When a client submits POST or PUT requests, the server has to ensure that the representation in the request is consistent with the business rules that govern what is valid and what is not. The media types used for representations along with documentation can describe client developers how to make such write requests that honor server's business rules.
The introduction of PATCH complicates this a bit more. In addition to describing valid resource representations for creating, updating, or doing other kinds of things with POST and DELETE, the server now needs to tell clients what combinations of partial updates are valid for use with the PATCH method. General diff formats would leave the door open for clients to submit invalid combinations of partial updates that violate the business rules on the server side. To avoid this, it is better to come up with application specific representations for partial updates. See How to Use PATCH for an example. Lack of standard media type for diffs should not hold you from using the PATCH method.
