Sound Advice - patterns

The GET pattern introduces a Uniform Interface for transferring identified sets of information from server to client. Clients and servers of different ages can communicate without impediment, and communication failures can be overcome.

The use of an acceptable types list in a GET request means that clients built during different phases of the architecture will generally be able to communicate. Document-based communication has a degree of flexibility built in with must-ignore parameters. The acceptable types list fills a gap when incompatible changes occur to the set of document types, for example a new type deprecates an old type such as atom depreciating rss for news feed syndication.

An explicit failure response allows problems in the architecture to be reported and repaired as required. The resubmit feature allows temporary or permanent changes to the architecture to be accommodated by components without explicit reconfiguration, simplifying management. Note, however, the potential security implications of allowing one component to reconfigure others. A predefined policy for which modifications are permitted and which are to be treated as failure cases can be useful in security-sensitive environments.

The potential exists in common transports such as HTTP for requests sent down parallel TCP connections or pipelined requests to be processed in a different order to that in which they actually return to Client. This could cause the client to become confused by "seeing" an older state after a more recent state. A simple solution is to hold off sending a GET request to a given URL when the previous related GET has not yet returned.

A client that is holding off sending the next GET request should queue the first such request for the identified URL. After this point it should not queue another GET request to the URL until the previous has been transmitted. There is no point queuing up multiple GET requests for the same URL. If the first request has not been issued by the time motivation to issue a second request comes around, a single request will fulfil the motivation behind both.

Twin consequences of the GET pattern are that interim states at URLs may be missed, and that the architecture as a whole does not become overloaded as the architecture is put under stress. Each GET retrieves the current state of the resource, so rapid changes may see the next GET arrive several changes after an earlier GET. These states will be lost unless an additional buffering mechanism is employed. The client will read back the current state rather than the old transitional states.

The flip-side of this behaviour is that clients are never stuck reading old data. They come completely up to date quickly and process the latest information available. Many algorithms for real-time processing will behave better under this scenario than if they are fed through old changes. The GET pattern can be adapted to a buffering model for algorithms that are sensitive to losses of interim states.

The Layering pattern increases latency for requests that are forwarded unmodified, but can provide performance and functionality improvements when caching or other modifications are applied successfully.

Introducing layers increases the complexity of security, architecture evolution, and simple component testing models. Security and trust become an issue as intermediaries move further from the ownership of either Server or Client. Intermediaries literally are the feared man in the middle of security parlance. An intermediary that chooses to function against the interests of either Client or Server will lead to compromised communication.

Evolution of the architecture can be stymied by intermediaries. Upgrade of client and server to participate in a new operation or pattern is often not sufficient. The presence of old intermediaries under control of neither the Client's agency or the Server's agency mean that work-arounds and fallbacks may be required when they otherwise would not be required.

Testing of components can also suffer. Testing against common Server implementations is not sufficient if an intermediary introduces an unknown factor. Intermediaries may re-order pipelined request messages, splitting a single TCP connection at the Client end into multiple connections by the time they reach the Server. This is a potential source of out of order processing and other mischief that testing only a Client/Server combination may fail to reveal.

The PUT pattern introduces a Uniform Interface for handing over identified sets of information from client to server. Clients and servers of different ages can communicate without impediment, and communication failures can be overcome.

The PUT pattern may require a change of thinking by developers with an imperative messaging background. PUT is not a request to make a particular change or particular kind of change to a set of data to reach an undefined end state. Instead, it is a request to make a set of data match a defined end state without specifying how the transition should be made. This is preferable to the imperative approach when it comes to network communications, because requests can be accidentally submitted multiple times without changing the meaning of the original request. Each subsequent request is interpreted as: "Please make no changes". This feature is called idempotency, and is necessary for dealing with any Response Lost message.

The use of an acceptable types list in a Types Not Understood response means that clients and servers built during different phases of the architecture will generally be able to communicate. Document-based communication has a degree of flexibility built in with must-ignore parameters. The acceptable types list fills a gap when incompatible changes occur to the set of document types, for example a new type deprecates an old type such as atom depreciating rss for news feed syndication.

An explicit failure response allows problems in the architecture to be reported and repaired as required. The resubmit feature allows temporary or permanent changes to the architecture to be accommodated by components without explicit reconfiguration, simplifying management. Note, however, the potential security implications of allowing one component to reconfigure others. A predefined policy for which modifications are permitted and which are to be treated as failure cases can be useful in security-sensitive environments. Incorrect reconfiguration of PUT requests can lead to the client issuing incorrect requests to other Servers, so policy should generally be tighter than that enforced for GET requests.

The potential exists in common transports such as HTTP for requests sent down parallel TCP connections or pipelined requests to be processed in a different order to that in which they were issued by Client. This could cause the server to use the wrong update, while the client sees only success responses. A simple solution is to hold off sending a PUT request to a given URL when the previous related PUT has not yet returned.

A client that is holding off sending the next PUT request should queue the first such request for the identified URL. After this point it should replace the queued PUT with each new request to the URL until the previous has been transmitted. There is no point queuing up multiple PUT requests for the same URL. The latest request should completely replace the effect of any previous one. This directs the server to transition its information directly from its starting state to its end state. In doing so, it can provide any internal optimisations available for efficient processing.

Twin consequences of the PUT pattern are that interim states at URLs may be lost, and that the architecture as a whole does not become overloaded as it is put under stress. Clients voluntarily discard intermediate states, so a server might have to make several internal transitions in order to catch up.

The flip-side of this behaviour is that servers are never stuck processing old data. They come completely up to date quickly. Many algorithms for real-time processing will behave better under this scenario than if they are fed through old requests. The pattern can be adapted to PUT to a new URL for each request for algorithms that are sensitive to discarding of interim states.

The orthogonal nature of document types, operations, and URLs throughout the architecture allow for freedom of evolution. This separation and evolution is supported through the major patterns of the architecture as old and new components interact, including GET and PUT.

The balance of control and freedom is capable of delivering application-level forwards and backwards compatibility that lasts for a relative eternity in our industry. For example, HTML and HTTP have been able to continuously evolve over a time-frame spanning decades.

More domain-specific document types will likely have shorter lifespans as they develop from local conventions to a point of widespread global agreement. However, as critical mass is created a semantic web where machines can communicate generally based on widely-understood conventions is likely to emerge without specific coordination or intervention.