Quick reference
| Latest version | Documentation |
|---|---|
| 1.0 (alpha) | REST API endpoints (FMR-TEMP: move to DEMO) |
The reference of public Gravity REST API endpoints is available at the link above.
...
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 a compliment 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.
...
As an example scenario, a Ticket could allow for two actions: one to retrieve its content and one to set the beneficiary. In this case, the endpoints could be defined as follows:
| Endpoint | Description |
|---|---|
| GET /tickets | retrieves the information of all tickets associated to the connected user |
| GET /tickets/123 | retrieves the information for the ticket with id 123 |
| PATCH /tickets/123 | (with additional form data {first name, last name} passed in the request body as JSON, see below for request format): sets the beneficiary of ticket 123 |
Notice that the same endpoint can allow for different granularities (in the example above, the complete list of tickets and a specific ticket).
...
The following table shows the supported HTTP methods and for which kind of action they are used:
| 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).
...
In addition, the HTTP status code of any unsuccessful call is taken from among the following:
HTTP error code | Meaning & use cases |
|---|---|
400 – Bad request | Request parameters passed with the request are missing or incorrect |
401 – Unauthorized | The action requires authentication and sufficient permission levels for the contact |
403 – Forbidden | The action is not allowed for the current contact (not enough privileges) |
404 – Not found | The resource targeted with the action does not exist |
415 – Unsupported Media Type | The request is not in the correct format, or the Content-Type header is not set accordingly. |
500 – Internal server error | An unforeseen server error occurred |
In the case an internal server error occurs, the error is logged to ease the follow-up of the issues. All other errors are not logged. In addition a 500 error response will always include fields to indicate whether the user was logged out and/or if the order was cancelled, allowing the client to correctly handle the following steps.
...