My Experience of APIs

I watched Nate Jones's TicTok last week. He talked about how APIs are becoming the interface to data. As I noodled on his words, I agreed with him, and it got me thinking about my history with APIs - more generally than his point.

I have been developing or calling APIs for a long time, and this got me thinking: weren't the MSDOS interrupts (related post) a form of API? We all know the right answer, so we will not say it out loud and move on.

But seriously. I remember creating an API for the DOS terminate and stay resident (TSR) module I wrote as the proxy for the server-based DBMS we wrote. This API used INT2F as the interface to the TSR.  We didn't expect CBASIC programmers to code to INT2F, so I had a callable C library that abstracted the internals. What we built was closer to something like ODBC, a generic API for retrieving data requiring you to write the query.

There was a period when our systems had a business layer and a data layer; the business layer represented business semantics, and the data layer represented the sproc/view/query/table structure. Weren't these all APIs? During the object-oriented period (which sounds like the Jurassic period), I didn't refer to them as APIs then; they were methods on an object.

We went from RPC to SOAP to REST, each an evolution to build distributed systems. All these are forms of APIs as well. Why? APIs are about creating a dependable contract that callers can depend on to create an outcome—not about the specific implementation technology. The "interesting" part of the API design process was how to design for reusability. And by interesting, I mean the part we spent a lot of time discussing. In the Enterprise IT space, we had enterprise architects who created taxonomies, libraries, and APIs that modeled the data and/or the business processes. Building models/services for the entire company didn't work, and a "single responsibility model" and "separation of concerns" were needed. Even now, we have engineers who have API design as a skill we depend on and use at some level of governance.

From these evolutions (and more) of APIs, I have learned they are hard. Why? Because API design is hard. Why? Because reuse is hard. This is why when we talk about APIs today, we don't think of them as static. Instead, we build them to be extensible as the needs evolve. Even designing for evolution, I have had more than my fair share of painful API deprecations.

I still love a good API design session.

Back-ing into Enterprise Web Applications

Sometimes I just don't know what to blog about. Is it just me? So when I don't have anything I feel is new or original, I guess I need to go back to something old. I know I have blogged about building applications in the browser before. Maybe not on this blog, but certainly on one of the many outlets I have had over the years. This topic has come up again as I consider the implications of technologies like Silverlight 2.0 and AJAX on building enterprise applications.

I really like the browser, but I am not sure it makes a great application platform. It makes me wonder why it seems like we need all these “other” technologies to make it a better platform. Take for instance the Back button. When browsing I am a big fan of the Back button (actually I am still a keyboard kind of guy and I use the backspace key - old habits die hard). Whether you like it or not, I think you will agree it is a standard that a lot of people now understand.

So when I host an application in the browser, what does the Back button do? Or perhaps a better question is what does the user expect the Back button to do? Why would they think it would do anything different?

"Hey, I'm in the browser. There's this big, prominent button with "Back" written on it". Why would I not want to press that?"

As it turns out using technologies like Silverlight 2.0 and AJAX seem to totally ignore this. They ignore it to the extent that you lose a lot of navigation context if you use it. For instance, say I am traversing down through a hierarchy. I get some number of levels deep and I want to
back up to a previous level - hit the back button? Better not if that traversal was being done using AJAX!

By the way this is not an entirely new problem; I first encountered this problem when an application I was reviewing for a client made such extensive use of session that the back button did not do what the users expected. So we spent a fair amount of time and energy coming up with ways to preserve the Back button functionality. First we found some hack that essentially
disabled the back button (ironically, by navigating Forward). Secondly we built our screens such that they used the query string to pass some basic context from one screen to the next; so that when you navigated back the browser would pass all the context back (since all it typically saves is the URL). An additional benefit we got from using the query string was that nearly every page was bookmark-able. The only exception was when you were in edit-mode; we not try to “save” transitive or volatile states.

Couple of side notes... It seems that the Back button works much better in ASP.NET even though the context is not stored n the query string. I have not taken the time to figure out the exact details of how this is working; but I imagine it has something to do with the browser caching pages and VIEWSTATE. Noteto self - go figure this out someday. Found this interesting article to a Java Framework to handle the Back / Bookmark problem introduced by AJAX. I have to imagine that some resourceful person has done something similar on Codeplex (or alike).

There is a time reporting application (to remain anonymous) we use at my current job that makes fairly good use of AJAX. That is in the sense that it does improve the response time and interactivity of the application. The downside is that I continuously get burned by use the back button. Argg!!

On the contrary, the MSDN library site does a pretty good job of mixing the two paradigms such
that when I hit back; the “right” thing happens. Sure, neither of these are enterprise applications (in fact comparing them to one another is hardly fair) but the problem remains.

In my mind I am questioning why we are still using the browser for enterprise applications at all. I know why, but I don’t know why. I mean, the reason why it’s so attractive is that it helps in two major areas; distribution and disaster recovery. Distribution is the whole thing that got
us here in the first place. The DR aspect is something I have been realizing more and more in this post Sept 11 world where DR is something I have to consider more and more. It’s just easy to deploy the web application to two physical sites (managed by some content manager); one the primary and the other the secondary. Give a large enough pipe you can load balance between
the two and have a scalable/HA solution to boot.

By why do they have to run in the browser? Why, why why? Here is what I
propose instead…

1. Build an application as a native Windows .NET application based on a 3-tier architecture. No HTML but some technology like WinForms or WPF.


2. For the middle tier I would like to use something the Entity Framework and LINQ. I have a question as to whether I am going to have a marshalling/serialization issues with this technology.


3. The applications are deployed using something like ClickOnce deployment.


4. In addition, I want to get rid of the requirement to have a specific .NET framework installed. I like the direction the Xenocode people are taking. Basically linking the .NET Framework into your application thereby bringing all the code and the dependencies down as part of download / install.

Just thought I would put some thoughts out here and see what if anyone is
actually listening. Hopefully you also were able to hand on until this point.
Regardless it’s a place for me to vent; kind of like my diary.