Design philosophy and standards to be reviewed before designing a client application to access Universal API.
|
Items such as the Web Service protocols used by Universal API, connectivity requirements, and recommended development skill sets. |
|
|
Recommendations for including capacity planning issues in the design and deployment of client applications. |
|
|
Security features in place for Universal API to support PCI compliance for PII Data, data masking, and HTTPS. |
|
|
The standards for use of key and reference values in Universal API. |
|
|
Encode/decode data that contain mappings between human-readable, travel-industry names and codes recognized by Universal API. |
|
|
System- and segment-related date and time formats used by Universal API. |
|
|
Limitations for traveler names on reservations that should be considered when designing input parameters for client applications. |
|
|
Universal API allows the use of schema versions from multiple releases when more than one product (for example, Air or Vehicle) is included in the request and the response creates a Universal Record. If only one product is included in a request, all schema versions must be from a single release. |
|
| Using Keys in Universal API Transactions |
Before Release 5.0, the keys used in Universal Record elements could be changed after they were assigned. As of Release 5.0 (May 21, 2013), Universal API has added the concept of durable keys, which keeps the keys from changing when Universal Records are retrieved and modified. |
Feedback / Support
