Semantic Response
Time your website with
WebWait - from the creator of AjaxPatterns.orgFrom Ajax Patterns
Note: This pattern is deprecated - see the patterns representing different types of Semantic Response: Plain-Text Message, XML Message, JSON Message.
Evidence: 2/3
Tags: Data Fact Information Raw Semantic
Contents |
Ajax/Javascript Programming and Usability in "Ajax Design Patterns" Book |
In A Blink
Diagam Server talks (balloon) HTML.
- Browser: "Tell me about the account balance."
- Server: "Cr3000000|Db1000000|Bal2000000."
Goal Story
Devi's producing a web statistics report so that managers can see how much each web page is being viewed. Fortunately, all the page access data is already exposed as XML by an existing RESTful service, being used by the billing department. Devi's browser script only has to grab an XML document from that service, and transform it to HTML.
Problem
What format should be used for server responses?
Forces
- Ajaxian applications usually require interaction between browser and server, which necessitates a form of message-passing.
- The browser contains display-related information, while the server usually contains business and application logic.
- It's undesirable to couple server-side services to browser display.
Solution
Have the server respond with abstract, semantic, data. Server-side services output data structures in the form of XML, JSON, or some custom, text-based, format. Because the data is not web-specific, it is often in a generic form which can be used by external applications as well as the browser script.
For example, imagine you're designing a weather website. You accepts queries like http://www.example.com/temperature/max/melbourne and respond with the current weather, using a semantic message like this:
<weather>
<location>Melbourne</location>
<date><year>2005</year>1<month></month<day>1</day></date>
<time>14:00</time>
<temperature format="celcius">32</temperature>
</weather>
Your own website's Javascript can access the data with an XMLHttpRequest Call and render it however it pleases. For example, it might run a switch statement to pick out a weather icon according to the current temperature. Meanwhile, external clients can also use the content easily. For example, an insurance company might pull in the weather data to help understand its risk exposure. Semantic data is easy for third-parties to access because its designed as an open API, free of application-specific detail.
The browser application can use semantic content in different ways:
- Transform some or all of it into HTML to present it to the user.
- Interrogate the content to decide what to do next.
- Store some or all of it for later use, e.g. as a Javascript variable.
- Modify it based on client state and upload it again.
Semantic Responses provide a clean separation by preventing the server from knowing HTML and encapsulating the entire UI in the browser. Message content and format must be suitable for manipulation on both sides. The precise message format will vary, but the key characteristic is raw, semantic, data; as opposed to code or display detail.
Note that the emphasis here is on the response from server to browser. Semantic content can also be passed from browser to server. Indeed that's what usually happens anyway. When the browser sends a GET query, the query usually consists of abstract concepts, e.g. in the query, http://www.example.com/games?manufacturer=namco (Not working), the manufacturer name and value are semantic content.
Decisions
Which message format to use?
Semantic Responses can be represented in several different forms. Each of the following is captured as a separate pattern.
Each of the above patterns discusses its own strengths and weaknesses. There are several factors involved:
- Browser-Side Environment: Which browser versions are being targeted will affect feasibility of message formats. In particular, XML support is limited in older browsers.
- Server-Side Environment: What sort of support is there for the message formats in the server-side coding environment. If using JSON, for example, is there a suitable binding for the server-side language?
- Developer Skills: What sort of skill base is available to deal with the message format? You might be tempted to use XML because you feel browser-based XSLT is the most elegant solution, but that requires XSLT talent.
- External Agents: The browser and the server may not be the only things that access the message. If the server is offering a generic REST service, the message format will need to be suitable for external applications too.
Real-World Examples
Google Maps
Google Maps downloads geographic information in a semantic, XML, format. See XML Message for more details.
Magnetic Poetry
Magnetic Poetry uploads user drag activity to the server in a custom, plain-text, format. See Plain-Text Message for more details.
Route Planning
Jim Ley's Route Planning For Round the World Flights downloads flight route information using JSON format. See JSON Message for more details.
Code Examples
Please refer to the Code Examples and Refactoring Illustrations for specific message types, Plain-Text Message, XML Message, JSON Message.
Alternatives
HTML Response
HTML Response involves sending display information as opposed to semantic data. Usually, the browser transforms Semantic Responses into HTML, whereas it's the server that handles HTML generation in the case of HTML Response.
Related Patterns
RESTFul Service
RESTful Services generally deliver Semantic Responses.
Ajax Stub
Ajax Stub relies on a generic framework to make calls between the browser and the server. The message from browser to server is a remote call including a function name and arguments, and the message from server to browser is a result. These are a form of Semantic Response, but developers using such frameworks don't need to be aware of the precise format.
Visual Metaphor
Sending a semantic message is like sending a textual description of an object - the facts are there and they can be rendered as the receiver sees fit, or used in other ways such as being synthesised with related descriptions.
