The AlpineBits Alliance is working on a standardisation of the exchange of events and mountain resort-related information in a working group named AlpineBits DestinationData. The first release AlpineBits of the destination data is named AlpineBits DestinationData 2020-04.
AlpineBits® DestinationData specifies a REST API for exchanging destination data based on the AlpineBits® DestinationData Ontology. The API is built on JSON:API v1.0 designed to support the client-server communication model, with a focus on system-to-system communication.
AlpineBits® DestinationData is built on:
• an OntoUML ontology that describes the conceptualization and scope of the standard;
• the RESTfull architectural style;
• the JSON:API v1.0 specification for REST APIs that exchanges JSON data through HTTP messages;
• HTTPS and basic authentication protocols for secure communication
• the JSON Schema standard – draft 7 for validation of messages in the AlpineBits® DestinationData
• the GeoJSON standard for modelling JSON geospatial data
• Schema.org structured data for inspiration for the design of resource types
The AlpineBits® DestinationData standard is intended for the exchange of touristic information between systems acting as clients and servers, where clients consume the data provided by the servers. The AlpineBits® DestinationData standard includes the definition of:
• specific server endpoints
• resource types
• support to GET requests
• request and response headers and parameters
• additional request features (e.g., pagination and hypermedia controls)
At the current version of the standard, the scope of AlpineBits® DestinationData covers exchanging data about events, event series, event venues, mountain areas, lifts, trails, snowparks, agents, and media objects.
Timeline AlpineBits DestinationData 2021-04
|by June 2020||proposals of new features by Members|
|August 2020||prioritisation of proposed features and start of the discussion together with unibz|
|February 2021||closing of the discussion|
|March 2021||revision & release candidate with unibz|
|April 2021||presentation of the new release|
For every route type defined in the standard, there is a JSON Schema that describes the structure of the messages it should return. Schemas can be used to programmatically validate messages against.
- If you are implementing a DestinationData server, you can use these schemas to check if your implementation is compliant with the standard. You can also use them at run-time to check if your server is sending correctly structured messages.
- If you are consuming data from a DestinationData server, you can use these schemas to validate the data you receive, which adds a layer of protection to your application.