2. Contents Digital-SNOWTAM Trial Introduction REST Introduction
REST in the Digital-SNOWTAM Trial
Why it is used
Architecture
How it is used
Example
AIXM XML Developers' Seminar

3. Digital-SNOWTAM Trial Introduction

4. Digital SNOWTAM Trial 2009-2010
SNOWTAM Message Sample  
ESSA S ESSA S0 C)01L F)71/71/71 G)01/01/01 H)69/63/60 SFH N)71/GOOD C)08 F)71/71/71 G)01/01/01 H)62/65/68 SFH N)71/GOOD C)01R F)71/71/71 G)01/01/01 H)70/66/68 SFH N)71/GOOD R)7/MEDIUM-GOOD T)RWYS AND TWYS CONT 10 PER CENT. APRONS CONT 25 PER CENT
Demonstrate xNOTAM benefits to end users -> Airlines
Verification of the AIXM 5 Surface Contamination model
Continue the testing of Web service standards
REST architecture
Start work on algorithms and open source code
structured SNOWTAM text to AIXM 5
AIXM 5.0 to SNOWTAM text

5. Scope Execution: Winter 2009-2010 Service provider End user Originator
Briefing
FPL
chart
FMS data
etc.
Originator
(Digital NOTAM)
End user
Pilot
Airline OPS
ATC
etc.
Image
Text
Application
AIXM 5
(Digital NOTAM)
xNOTAM Trial
(origination only)
xSNOWTAM Trial
(end-to-end)

6. Trial – application architecture

7. Digital SNOWTAM Trial (2009-2010)

8. REST Introduction

9. REST Representational State Transfer An architectural style
A technology agnostic abstraction
The Web is RESTful
REST
Representational State Transfer
It is an architectural style. An abstraction that could be implemented with any technology.
Some people have made a (weird) proof of concept REST over SOAP implementation.
The largest known implementation of a system conforming to the REST architectural style is the World-Wide Web. In fact, REST can be considered as a post-hoc description of the features of the Web that made the Web successful.
(OFTEN LEAD TO REStful Web Services E.g. Amazon S3 REST API.)
AIXM XML Developers' Seminar

10. Key principles Identifiable Resources Representations Hypermedia
Uniform Interface
Actions – Verbs
Client-server
Transparency and layering
Type of data
REST is about ***resources***, not services
AIXM XML Developers' Seminar

11. Resources
A resource is a real thing that can be acted upon with a request
Anything that can be named and identified can be a resource
They are found/identified using URIs
Unified Resource Identifier
= network address ~ URL
Collection URI (../airports)
Member URI (/airports/732d64d4-cd11)
Anything can be a resource (an airport, a runway, a list of taxiways, a book, a shopping cart...)
A resource is a real thing that can be acted upon with a request
Probably anything that can be converted into an Object (in OO) could be converted into a resource (no one-to-one relationship)
These are identified using URIs WIKIPEDIA: Uniform Resource Identifier (URI) is a string of characters used to identify or name a resource on the Internet.
In its current strict technical meaning, a URL is a URI that, “in addition to identifying a resource, provides a means of locating the resource by describing its primary access mechanism (e.g., its network ‘location’).
AIXM XML Developers' Seminar

12. Resources and time Resources can vary over time.
The only thing that must be static is the semantic of the mapping (name).
An id doesn’t identify a particular state of the resource, so subsequent calls to the same resource can give different results, depending on the current state of the resource
AIXM XML Developers' Seminar

13. Representations Resources are always accessed through a representation
Captures the current or intended state of the resource
There can be more than one (html, xml, pdf…)
HTTP provides well known/standardized content types and content negotiation
The data transmitted to and from the resource is called a representation. This is a conceptual idea, it means that the server doesn’t send its database, but something that represents one or more records.
HTTP/Content-types allows for machine to machine communication. A computer can tell the other one or more representation(s) he is able to process, in which priority, so the server can decide which representation to deliver
---
It can be a copy of the file or a description of it.
The interaction of the representation on the resource is determined by the verb.
AIXM XML Developers' Seminar

14. Hypermedia Allows access to related resources
Master-detail and other connections
URIs in hypertext links
Links should always be provided by the server
Enables seemless evolution and distribution
Different application and servers
AIXM XML Developers' Seminar

15. Uniform Interface
Once you know a resource’s ID, you can interact with it in a single standard way
Limited set of operations (verbs) in HTTP: GET, PUT, POST, DELETE
Pre-defined semantics allows for optimizations
Resource’s ID is just a like a “void pointer”. You have no idea of what you can do with it.
An interface you can rely on, with pre-defined semantics, verbs like get/put a new representation/post. Defined in http specification.
Ex: Enables caching. GET is a safe operation. You know you can do 1000s of get without side effect. (obviously, it depends on the implementation, but BaseCamp/Google bot example with links to delete stuff)
AIXM XML Developers' Seminar

16. Actions GET Used to read a resource or as a query
Should be side-effect free
POST
Creates a new resource or invoke arbitrary processing
PUT
Updates the resource with new data and create it if necessary
DELETE
Removes the resource
AIXM XML Developers' Seminar

17. Client Server Interactions
Interactions in both directions: from and to the server
Interactions are stateless:
no client context stored on the server between requests
Once the resource has been found, an action can be performed.
These use the HTTP verbs: GET, PUT, POST and DELETE
AIXM XML Developers' Seminar

18. Transparency / Layering
An application can interact with a resource by knowing two things: the identifier of the resource and the action required. That’s all!
How the representation is found should be transparent to the user
Layered system A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.
What happens behind the scenes stays behind the scenes.
AIXM XML Developers' Seminar

19. REST in the Digital-SNOWTAM Trial

20. Why it is used
Support the provision of AIXM 5.1 data to end-user applications
The REST interface shall enable digital users to:
Query the Digital SNOWTAM database for the list of airports contained in the database and select one of these airports;
Get the list of airport’s features for a selected airport;
Get the surface contamination records for each such feature;
Get the related feature through xlink:href;
Get the SNOWTAM text and the free text translation associated with an Airport.
Read-Only
Except for the list of Airports always returns an AIXM Basic Message which contains features
There is no AIXM message yet for list of airports
AIXM XML Developers' Seminar

21. Architecture The REST framework used is Struts 2 REST plugin.
See for more information.
REST plugin in turn uses the Convention plug-in:
AIXM XML Developers' Seminar

22. Implementation Only GET is needed for the trial.
AIXM XML Developers' Seminar

23. Workflow In order to interrogate the database:
request the list of airports
select one airport and use the xlink:href to get the details about this airport
select a related feature and use the corresponding xlink:href to get the details about it
The xlink:href is a URL compliant to the Digital SNOWTAM REST request structure
Use the UUID for subsequent calls
Xlink href: see Hypermedia. It is generated by the server
AIXM XML Developers' Seminar

24. Base URL Base: http://<server>/<app>
E.g.
Then add a Suffix:
/<REST suffix>
Will work on HTTPS
AIXM XML Developers' Seminar

25. Find Airports Suffix: /airportheliports[?designator=<pattern>]
There are about airports/heliports in the database so…
Optional Parameter:
The pattern is of the form [A-Z*]{1,4} where * is the wildcard character.
Pattern samples:
EB* matches any designator beginning with EB
*BBR matches any designator ending in BBR
E*R matches any designator beginning with E and ending with R
The response to this request is not AIXM5.1-compliant since AIXM5.1 doesn’t define the concept of list of airports/heliports.
Can add date&time if needed.
AIXM XML Developers' Seminar

26. Query an Airport Suffix:
/airportheliports/<gml:identifier>[?features=yes/no&contaminations=yes/no&date=<date&time>]
Mandatory parameter:
gml:identifier – UUID
Optional parameters:
date - <date&time> is the search date&time
features - specify if xlink:href pointing to related features must be included in the results, e.g. runways, taxiways, etc
contaminations - specify if contaminations must be included or not in the result
Use the gml identidfier from the Find Airport stage
Here are a few remarks valid for all the suffixes described below:
date is an optional parameter and <date&time> is the search date&time in the format dd/mm/yyyy hh:mm (e.g.: 11/06/ :35). In each case, the response will be limited to data valid at that date&time. If no date&time is provided, the current date and time is used.
features is an optional parameter to specify if xlink:href pointing to related features must be included in the results,e.g. runways, taxiways, apron of an airport or runway directions of a runway. Possible values are yes and no. If missing, no is assumed.
contaminations is an optional parameter to specifiy if contaminations must be included or not in the result. Possible values are yes and no. If missing, no is assumed.
AIXM XML Developers' Seminar

27. Examples

28. 1 – Create Contamination
Use Bromma to create a contamination
AIXM XML Developers' Seminar

29. 2 – Use REST to find the airport
<ResultList>
<AirportHeliportFeature designator="ESSB" id="77a0de0e-277a-4824-a561-2ba779a3658c" href="
</ResultList>
Use FireFox with text link plug in:
AIXM XML Developers' Seminar

30. 3 – Find SNOWTAM Text
<aixm:annotation>
<aixm:Note>
<aixm:definition>snowtam-icao</aixm:definition>
<aixm:translatedNote>
<aixm:LinguisticNote>
<aixm:note lang="eng">
SW** ESSB (SNOWTAM A)ESSB B) C)12 F)3/2/2 G)1/1/1 H)2/3/3 BRD )
</aixm:note>
</aixm:LinguisticNote>
</aixm:translatedNote>
</aixm:Note>
</aixm:annotation>
AIXM XML Developers' Seminar

31. 4 – Get Airport data …
<aixm:associatedRunways>
<aixm:associatedRunway id="12/30" xlink:href="
</aixm:associatedRunways>
AIXM XML Developers' Seminar

32. 5- Get Runway contamination
<aixm:areaContaminant>
<aixm:RunwaySectionContamination>
<aixm:observationTime> T09:00:00Z</aixm:observationTime>
<aixm:depth uom="MM">1</aixm:depth>
<aixm:frictionEstimation>MEDIUM</aixm:frictionEstimation>
<aixm:frictionDevice>BRD</aixm:frictionDevice>
<aixm:obscuredLights>NO</aixm:obscuredLights>
<aixm:layer>
<aixm:SurfaceContaminationLayer>
<aixm:layerOrder>1</aixm:layerOrder>
<aixm:type>WATER</aixm:type>
</aixm:SurfaceContaminationLayer>
</aixm:layer>
<aixm:section>2_THIRD</aixm:section>
</aixm:RunwaySectionContamination>
</aixm:areaContaminant>
AIXM XML Developers' Seminar

33. 6 - Time based
AIXM XML Developers' Seminar

34. AIXM 5.1
TEMPDELTA and a BASELINE
AIXM XML Developers' Seminar