This post originated from an RSS feed registered with Java Buzz by Carlos Perez. Original Post: Principles of Loosely Coupled API's Feed Title: .:Manageability:. Feed URL: http://www.manageability.org/blog/stuff/rssDisabled?portal_status_message=Syndication+is+Disabled Feed Description: Random thoughts on the manageability of complex software. Latest Java Buzz Posts Latest Java Buzz Posts by Carlos Perez Latest Posts From .:Manageability:.

Bill de hÓra has a very good blog entry "Foundations for component and service models".   It seems to jive very well with my thoughts on loosely coupled architectures.  Bill is dead on right when he says that idiomatic java isn't a place to get inspiration on how to build loosely coupled architectures.  However, I'm going to qualify my agreement, Java idioms are extremely useful, however when you get to "programming in the large" it's becomes a whole different ballgame. 

Bill has a couple of very interesting recommendations:

1. Avoid changing or extending the interface methods.
2. Control change by using a dictionary interface.
3. Calls should return documents not objects.
4. Avoid binary compatability.
5. Don't confuse an API with a contract.
6. Version the contract.
7. Don't build an API for data transfer.

Again, its instructive to look at my "Loose Coupling" table to make some comparisons with the list above. Bill's first recommendation appeals to a REST style.  This recommendation favors the REST style of using a fixed set of verbs (see "Interface" in table).  The 2nd recommendation is the use of dynamic typing (see "Typing" in table).  The 3rd recommendation is appeals to coarser grained message passing (see "Messaging" in table).  The 4th recommendation is the concept of leveraging a lingua franca .

Now, recommendation 5,6 and 7 are all quite unique.  The 5th recommendation says that there's more to interaction that just the API's, rather we should all consider contracts.  This of course has been hinted on by all those Web Services choreography initiatives.  Being able to introspect the definition of how parties interact is something completely absent in conventional programming.  The 6th recommendation is extremely interesting and I would like to see how he goes about doing this.  Finally, the 7th recommendation is an appeal to be pragmatic.

With these new recommendations, I think its time to update my original "Loose Coupling" table: