The Netflix blog recently had an interesting post on how they are transitioning into a new approach for API design. The basic idea is that instead of just exposing a number of generic operations each client type have their own adapters where instead of making a number of network calls to get data for one view the client just makes one call and the distribution if calls is done on the server, as is any client specific packaging. I found this intriguing for a number of reasons. First of all this reminds me of something I was exposed to in a project 1999. In that project we had most of our business logic in stored procedures (give me a break; it was the 90s and seemed like a good decision at the time) but each form in the UI had a single stored procedure it called to get all data it needed. That part actually worked quite well since our UI developers could write simple stored procedures. Ever since I've been a big fan of providing both the building blocks a client can use if needed but also convenience APIs, which happens to have another name; service facades.
I guess the most interesting thing about Netflix's approach seems to be that they generally drop support for the publicly available, building block APIs and forces each client team to implement their own service facade that suit their needs. I strongly suspect there is a common library to implement a facade that handles the building blocks but that is not important. Bottom line is it looks like Netflix going to be using a service facade pattern and in them doing so highlight the importance of good abstractions so that the same service can be accessed both through REST, raw TCP and maybe even RPC calls.