This introduction will start by giving you some common information about the REST API, before walking you through the different aspects of what is provided by the Wedia REST API.
...
HTTP Basic authentication : uses the credential of a Wedia DAM user.
JWT token authentication (since
) : uses the credential of a Wedia DAM user.Status colour Purple title 11.15.0 bearer authentication
cookie authentication
Application Token authentication
These tokens are linked to special “application users” that you can be created in the REST API admin dashboard. This is an alternative to using real users credential, as with the previous authentication methods, and this authentication methods fits when the API caller is indeed an automated application, without having a user logged in. These “application users” can be active for a limited time only. To use this application token, use a basic authentification with the following header :
In the REST API dashboard, you will create a new Application Token, and will get in return a key and secret. The key as will serve as the login and the secret as password for a Basic authentication.
Please set the header for application id: X-WEDIA-REST-APPLICATION
You may also set the optional header (optional) for user id: X-WEDIA-REST-APPLICATION-USER
Sessionful authentification (since
) : this allows to create a stateful session, that will be shared by all components of the application : API, Portal, BackOffice. This can be useful for recreating a full featured experience for the connected user, through the API. The session is maintained through two session based cookies : JSESSIONID cookie and x-wedia-api-token cookie.Status colour Purple title 2021.4.0 Please note that as of
, the Session based authentication that also exists in the API is no longer enabled in the API as it offers a CSRF-type attack surface.Status title 11.15
Endpoints Common Parameters
...
This section explains these API-wide parameters.
lang
By setting this parameter you will set up which localized data you wish to get as the result of your query.
...
A special section about localization will help you learn more about translations, and locales.
debug
On development mode, exceptions stacktraces, and other additional debug informations, are exported to the JSON response. In production mode, any error will respond, this informations are no longer reported (since version
| Status | ||||
|---|---|---|---|---|
|
The debug parameters will set up the mode, development or production. Its value is a boolean true (default) or false.
state
(since version
| Status | ||||
|---|---|---|---|---|
|
...
To limit the load on response times, prefer to send an identifier (or short data structure) and manage an association map in the client to find the information that allows you to find the request (or the component that is supposed to process the response).
restapiconsumer (obsolete)
(from version
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
...
By default, the localization language is based upon the web browser language locale. If the web browser has no locale, it uses the header Accept-Language.
It is also possible to force a locale by using the request parameter lang. Its syntax is similar to the header.
If the requested language is not supported the service will respond NOT_ACCEPTABLE.
HTTP methods
By default, the server only accepts GET, HEAD or POST methods.
If you need to use other methods such as “PUT”, then te endpoint should be called with the POST method and the name of the actual method should be set in a specific header.
We support 3 alternative headers of your choice :
...
X-HTTP-Method-Override (Google/GData HTTP method overwriting)
...
X-HTTP-Method (Microsoft HTTP method overwriting)
...
Errors
When an error is returned by the API, the HTTP status provides its HTTP error type.
...
HTTP Code | API Code | Definition |
|---|---|---|
404 | 404/900 | Unfound object |
404 | 404/901 | Unfound file |
403 | 403/900 | Unaccessible property (or forbidden) |
403 | 403/901 | Unauthorized localized value modification |
400 | 400/900 | Bad value |
400 | 400/901 | Expected content is missing |
405 | 405/0 | Method not allowed |
405 | 405/1 | Unsupported method |
503 | 503/0 | REST API Service is unvailable |
503 | 503/0 | REST API Imaging Service is unvailable |
503 | 503/42 | Server is in maintenance |
406 | 406/0 | Not acceptable mimetype |
406 | 406/1 | Not acceptable charset |
406 | 406/2 | Not acceptable language |
401 | 401/0 | Authentication error |
404 | 404/0 | Resource not found |
404 | 404/1 | Unknown property |
500 | 500/0 | Internal server error |
500 | 500/1 | Data access error |
400 | 400/0 | Missing parameter in request |
400 | 400/1 | Missing parameter value in request |
400 | 400/2 | Multiple parameter value not allowed |
400 | 400/3 | Parameter value not possible |
400 | 400/4 | Invalid connection |
400 | 400/5 | Multiple parameter value not possible |
403 | 403/0 | Access denied |
403 | 403/1 | User disabled |
401 | 401/1 | Invalid token |
401 | 401/2 | Expired token |
401 | 401/3 | Token not yet valid |
401 | 401/4 | Invalid ID token |
HTTP methods
By default, the server only accepts GET, HEAD or POST methods.
If you need to use other methods such as “PUT”, then te endpoint should be called with the POST method and the name of the actual method should be set in a specific header.
We support 3 alternative headers of your choice :
X-HTTP-Method-Override (Google/GData HTTP method overwriting)
X-HTTP-Method (Microsoft HTTP method overwriting)
X-METHOD-OVERRIDE (IBM HTTP method overwriting)