Five faces of a web application: Web GUI, web service, CLI, API, data
While working on our new web application DC5, a total rewrite of its predecessor DC4, it occurred to me that you could say there's five ways of looking at a web application, five interfaces that matter to its users.
Getting any of these right, making it beautiful, is an art in itself. Getting all of these right seems to be the ultimate goal for a web application, and should result in a wonderfully versatile and transparent piece of software:
- The web interface: Naturally, the GUI (graphical user interface) will get a lot of attention while you're developing your web application. Functionality, design, usability, security, browser compatibility are the important things to consider. Often, there's two web interfaces, one for administrators and one for end users. Expect to see lots of web applications exposing a beautiful HTML user interface, but neglecting some of the following interfaces -
- Web services: Today, people start to expect that your web application will provide network access to its data in the form of XML over HTTP (be it SOAP, XML-RPC or REST). This is a good thing - integrating data from multiple sources and locations is becoming so much easier once your data has URLs and a well-defined XML format. Seems to me that choosing protocols, URLs and formats takes some time...
- Command line interface (CLI): Probably the most-neglected interface of web applications. Imagine you're an adminstrator and have to import lots of data into the web application. You will not want to do this through a web page, nor through a web service. Or you want to do a batch update, and the modifications you'd like to apply would be easy to express in Perl, or in XSLT: A good web application will provide you with command line executables or scripts, allowing you to process its data with standard Unix tools. You have the most power at your fingertips while you're at your server's command line!
- Application Programming Interface (API): Even if you weren't planning that users interact with your web application from within a programming language, you would still need to develop and maintain a consistent API for yourselves (the application developers) - you use it to implement the three interfaces above. Once you have such an API, you may as well document it and advertise its use to others. Encouraging users to program add-ons using your API may at best result in a community contributing valuable code to your application. And at least, the users who have knowledge of your application's programming language will less likely be drawn away because of missing features.
- Data structures: What will happen if you throw away all your code, keeping just the data of your web application? Will there be a meaningful directory or database layout, easily accessible and comprehensible by outsiders, or by yourselves two years later? It will be even better if your users know which data they may modify directly, without using your application; this would bring the power of SQL (or find/grep/sed) to them.