Dokumentacja API ShipX
API platformy Ship X jest głównym interfejsem wymiany danych z systemem centralnym. Przy jego użyciu można odczytywać i modyfikować dane.
Dostęp do danych jest chroniony. Mechanizm autoryzacji oparty jest o standard OAuth 2.0.
Zapytania podpisywane są przy użyciu access tokena, na tzw. okaziciela (ang. Bearer Token), tzn. że ktokolwiek użyje prawidłowego tokenu, uzyska dostęp do określonych zasobów przez API.
API jest interfejsem stateless.
Kody odpowiedzi HTTP
Kody odpowiedzi HTTP, które mogą wystąpić w odpowiedzi od serwera:
Kod HTTP | Opis |
|---|---|
| Odpowiedź prawidłowa. |
| Zasób został utworzony. |
| Odpowiedź prawidłowa, żadna wartość nie została zwrócona. Spotykane np. podczas usuwania zasobów. |
| Dane przesłane metodą |
| Dostęp do zasobu wymaga autoryzacji. |
| Brak lub zestaw uprawnień jest niewystarczający, aby uzyskać dostęp do określonego zasobu. |
| Zasób nie został odnaleziony. |
| Wystąpił błąd po stronie serwera. |
Błędy
W przypadku wystąpienia błędu API zwraca obiekt błędu, który zawiera następujące atrybuty:
Atrybut | Typ | Opis |
|---|---|---|
| Integer | Kod odpowiedzi HTTP. Zobacz tabelę powyżej. |
| String | Klucz błędu, jednoznacznie identyfikujący problem. |
| String | Prosty, łatwy do zrozumienia opis błędu. Opis błędu może ulegać zmianie i nie należy opierać na nim warunków w kodzie.
|
| Object | Szczegóły dotyczące błędu, który wystąpił, np. lista błędów walidacji. Może być puste w przypadku błędów, których nie dotyczy. |
Przykładowa odpowiedź:
HTTP/1.1 404 Not Found
{
"status": 404,
"error": "resource_not_found",
"message": "Resource you are looking for are not found",
"details: {}
} W przypadku zapytania przesłanego metodą POST lub PUT mogą wystąpić błędy walidacji. Szczegóły na ich temat umieszczane są pod atrybutem details w odpowiedzi:
HTTP/1.1 400 Bad Request
{
"status": 400,
"error": "validation_failed",
"message": "Data sent by POST or PUT request are not valid. Check details for more info",
"details: {
"name": ["required", "too_short"],
"post_code": ["invalid_format"]
}
} Kluczami obiektu details są nazwy atrybutów przesłanych metodą POST lub PUT, dla których wystąpiły błędy walidacji. Natomiast ich wartości to tablica kluczy błędów, które są prawdziwe dla przesłanej wartości. Poniżej opisana jest lista generycznych kluczy błędów walidacji.
Klucze błędów
Poniższa tabela przedstawia klucze błędów, które mogą zostać zwrócone przez serwer, wraz z możliwymi kodami HTTP:
Klucz błędu | Kod HTTP | Opis |
|---|---|---|
|
| Szukany zasób nie został odnaleziony, np. adres URL jest niepoprawny lub zasób nie istnieje. |
|
| Przy przesyłaniu danych metodą |
|
| Dostęp do zasobu jest niemożliwy, ponieważ zapytanie nie zostało podpisane kluczem access token. |
|
| Dostęp do określone zasobu jest zabroniony dla tego zapytania (np. z powodu braku lub niewłaściwego zakresu uprawnień). |
Klucze błędów walidacji
Poniższa tabela przedstawia generyczne klucze błędów walidacji, które zwracane są pod atrybutem details dla odpowiedzi błędu validation_failed:
Klucz błędu | Opis |
|---|---|
| Podanie wartości jest wymagane. |
| Podana wartość jest nieprawidłowa. Szczegóły w dokumentacji opisującej zasób. |
| Podana wartość jest zbyt krótka. Szczegóły w dokumentacji opisującej zasób. |
| Podana wartość jest zbyt długa. Szczegóły w dokumentacji opisującej zasób. |
| Podana wartość jest zbyt mała. Dotyczy głównie wartości liczbowych. Szczegóły w dokumentacji opisującej zasób. |
| Podana wartość jest zbyt duża. Dotyczy głównie wartości liczbowych. Szczegóły w dokumentacji opisującej zasób. |
| Podana wartość ma niepoprawny format, np. gdy w pole numer telefonu zostały wpisane cyfry. |
Oprócz powyższych błędów walidacji mogą wystąpić inne, które są specyficzne dla określonych zasobów. Szczegółów należy szukać w rozdziałach właściwych dla tych zasobów.