If I don’t publish more often on this blog, this is because I don’t want to speak about what I don’t know !

This post has been published in reaction to many other posts which emphasize the fact that this move is the end of mashups because Google takes control over the way search results are presented in your pages.

My point is that this is not true and that the real difference is a shift from server side to client side mashups.

I appreciate the difference between a SOAP service and a JavaScript API, but in this context where you focus on client side Web programming which is very largely dominated by JavaScript, the difference will be very thin for most developers.

Eric

I absolutely disagree with you. How can you say that it makes no difference ? It makes me wonder if you just know what you’re talking about !

For sure, for the lambda web programmer, the difference may be very light. Probably, he will even consider it easyer to use a client-side javascript API to “embed” a search facility in its pages.

But from a more architectural point of view it makes a lot of difference ! The main point of the SOAP protocole is that it makes services accessible from almost any piece of software, not just a web client. The other point of SOAP is that this is standardized which guarantees the independance of server and client implementations.

You suggest that calling the API from a server-side javascript engine could do the trick, but this would just be a very ugly hack, which would not be acceptable for millions of good reasons.

So it is just pointless to compare a SOAP service and a proprietary client/server architecture (with a javacript client API).

However I agree with your conclusion : both may be useful and one could be based on the other (would the other be REST or SOAP).

If they really want to do so, they should be able to authentify their API and use a standard protocol that is implemented in all the browsers than create a new network protocol which would be complex if not impossible to implement in the different browsers, don’t you think so?

As for Microsoft, they can be tempted to create their own client/server protocol but they also need to make it work in other browsers if they want to generalize on the Web.

The browsers war is what has left the Web open and I don’t see what would make that change in a near future!

As to how would they do that, a virtual machine should be good enough. Microsoft already put a .NET VM into their SQL Server 2005. Wouldn’t the new Java Virtual Machine be a good candidate for such a system?

I haven’t double checked, but I had assumed that behind the scene they are still using HTTP(S) and a serialization format such as XML or JSON.

If they were be bypassing HTTP, I agree that this would be more worrying.

On the other hand, why and how would they do that? I would think that client side JavaScript miss the low level networking functions that would make that possible and that HTTP(S) is really the most sensible option.

Eric

Microsoft recently made the same kind of shift with its Ajax API, and one could wonder whether this kind of move wouldn’t eventually lead to merely bypassing the HTTP/CGI layer, therefore connecting directly client with the data server, where the data could also be preprocessed in all kind of useful ways before retrieval.

For instance, there should become possible to retrieve web pages directly from SQL Server 2005, build from any internal and external data, since the server itself includes a full .NET virtual machine. It would be interesting to watch Google moves to this respect.