| Warning |
|---|
This API is not public anymore. Existing endpoints are maintained, but no support will be provided for new integrations. |
Quick reference
| Latest version | Documentation |
|---|---|
| 1.0 (alpha) | (FMR-TEMP: move to DEMO) |
The reference of public Gravity REST API endpoints is available at the link above.
Every endpoint is described and the required parameters are presented. A graphical interface allows to test every endpoint and consult the Models used by the interface.
Usage notes
Currently, REST APIs are still coupled with internet points of sales. This means, that calls done on the REST API, must be performed starting from the internet URL, and are accessible through the following URL pattern:
https://<point of sales url>/tnwr/v1/
This will be subject to change in future versions, which will be hosted in a separated and centralized environment. The context parameter, set in the header X-Secutix-Host (see Context handling section below) is required but redundant right now, but will allow in the future for a seamless migration to the new API hub.
Introduction
This document presents the architectural principles of the Gravity REST API and provides information about its usage. This API is incomplete and will progressively be enhanced in parallel to the Gravity (FMR-LINK) project.
This REST interface is an addition to the already existing interfaces provided by SecuTix. It is an interface that works at a higher level than the interfaces provided by the back-end services. Its goal is to provide a simple set of entry points that aggregate all the information required for a front-end implementation, and that allow the user interactions involved in a ticketing purchase process. As an example, the catalog entry points return products that are pre-processed: they contain the right availabilities, propose prices that are accessible to the specific user and offer all information that is required for user interaction. User interactions, like adding a ticket to the shopping cart, are simplified and executed through calls to the interface.
...
| Operation | HTTP method |
|---|---|
Create | POST |
Read | GET |
Update | PUT (complete data) - PATCH (partial data) |
Delete | DELETE |
...
As a convention, parameters required for actions on particular resources (for instance actions applied to a specific ticket in the previous example), are defined as path variables. Query parameters are only used to refine the request (like filtering or sorting). When a frequently used action requires the setting of specific parameters, then it is aliased (i.e. a new action with abstraction of parameters).
...