If you have been following along in my previous articles about Roy Fielding’s REST Dissertation, you should have a very high level understanding of the paper as well as a grasp on his view of architecture. In this article I’ll go over the paper’s concept of a network application while highlighting its unique challenges.
Software is often given categorizations such as network software or application software. The paper makes a clear distinction between those two types, and then denotes a third type of software. Network software is defined as any software that moves bits over a connection without knowing what those bits are. Application software, on the other hand, takes into account the overall goals of a user. A network-based application would be software that takes into account the goals of a user and is mindful of how its bits move over the network. The REST dissertation concentrates on the network-based application domain.
There are almost always consequences in the form of trade-offs (compromises) when obtaining an architectural property. This characteristic makes architecture evaluation very elusive when coupled with a large number of desirable properties, as is the case with network-based applications. There are twelve architectural properties that are used to compare trade-offs between architectural styles in the paper. The following is a brief description of them.
Performance, particularly user-perceived performance, is revisited often throughout the paper. Some of the most prominent constraints, e.g. statelessness, in the REST architecture were done for performance reasons. Statelessness also addresses the problem of partial failure and reliability, which is a among the most significant challenges in network based software. Scalability is closely tied to performance in a network application because you want to be able to reap greater performance when adding more resources. This is especially important when considering Internet-scale applications which can have unanticipated load.
Simplicity and modifiability are needed to understand the application as a whole, and to be able to change it once it is deployed. In a system that can be deployed to more than tens of thousands of servers, stopping the system in order to evolve or extend it would be inefficient and probably futile. With a large user-base, it’s more practical to let some users customize a service on the client side. Still others may need to configure a server side component to point to a new sub-component. Optimally, it is desirable for components to be reusable without modification, in the same environment, for new purposes. If the code can be used in a different environment, it is said to be portable.
Visibility allows the application to play nice with the network. With high visibility, components can be made to assist with caching and therefore performance. This is because the messages sent between components are easily accessible (hence visible) to intermediaries on the network. Firewalls are network components that benefit from visibility in an application’s architecture by increasing security through inspection of messages.
Together these properties form the basis for comparing network-based application architecture styles. In the future I’ll revisit these properties individually while reviewing some of the more notable styles in the paper. In my next article we will take a look at the requirements for the web.