Timesheets-Server
Timesheets server
|
API je postaveno tak, aby je bylo možné používat i na nezabezpečené síti (internet). Ověření přístupu k api může probíhat dvěma způsoby:
Obě metody jsou potřebné a musejí pracovat vedle sebe.
Předpokládá se, že webová část aplikace bude moci běžet na internetu a bude přístupná libovolným webovým prohlížečem. Certifikát proto musí být vystavený známou certifikační autoritou (například Let's Encrypt). Přístupy k API z webové části by měly být zabezpečené stejně - jménem a heslem. Certifikát vystavený známou certifikační autoritou nezpůsobí protesty u běžných webových prohlížečů (Firefox, Chrome).
U klientů by zadávání jména a hesla naopak vedlo k bezpečnostním rizikům a ke složitému nastavování. Proto se klienti prokazují vlastním certifikátem. Takový certifikát je ale složité a drahé získat pro zařízení schovaná ve vnitřní síti, nehledě na distribuci klíčů na jednotlivé klienty. Navíc mohou být ve vnitřní kladené mnohem nižší požadavky na zabezpečení. Proto je pro potřeby klientů vytvořená vlastní certifikační autorita, která je známá klientům i webovému serveru, a místo jménem a heslem se klient ověřuje pouze svým certifikátem. Certifikát může mít v porovnání s běžnými komerčními certifikáty prodlouženou platnost a odpadá starost o jeho periodické obnovování a distribuci na klienty. U běžných webových prohlížečů by tento způsob vedl k pracnému importu certifikátů do všech prohlížečů, které by měly přistupovat k API. U klientů jsou certifikáty a klíče součástí instalačního balíku celé aplikace.
Adresy pro přístup k api (příklad):
Podstatné je, že obě metody ověření používají jiný název serveru, ačkoliv vše končí ve stejné části kódu. Jedině takto lze použít různé certifikáty pro různé způsoby ověření.
Data se předávají v JSON formátu:
Pro získávání dat a manipulaci s daty se používá jednoduché REST api, používají se příkazy GET, DELETE, POST a PUT.
K přístupům lze použít různé obvyklé prostředky, například curl nebo wget (z povelové řádky).
Pro přístup k datům je nutná autentizace. Po úspěšné autentizaci je nastavená session cookie - jméno této cookie je unikátní pro každou session. Adresa pro přihlášení je /authenticate, parametry user a password:
Přihlášení s wget:
Také příkaz curl umí ukládat cookies v souboru a použít je při dalším požadavku:
Při úspěšném přihlášení odpovídá server 200 OK. Při neúspěšném přihlášení se posílá chyba ověření.
V dalším textu se předpokládá, že je autorizace provedená a pomocí parametrů se předává session cookie. Parametry pro předávání cookie se neuvádějí.
Pro manipulaci s daty se používají tři základní příkazy protokolu http: GET, PUT (POST) a DELETE.
Příkazem GET se získávají data ze serveru. U jednoduchých seznamů obvykle není nutný žádný parametr. U dotazů pro zjištění informací o konrétním objektu je obvykle nutné zadávat id jako další část cesty:
Vrací požadovaný dokument (zformátované pro lepší čitelnost):
V případě chyby vrací json popisující chybu, například:
Příkazem PUT se ukládají data na server.
V případě úspěchu vrací json:
nebo v případě chyby:
Příkazem DELETE se data ze serveru mažou:
V případě úspěchu vrací json:
nebo v případě chyby:
HTTP kód | error | reason | Popis |
---|---|---|---|
400 | bad-request | Could not parse JSON data | Předaná data formátu JSON se nepodařilo rozluštit |
400 | bad-request | Data must contain ID | V JSON datech chybí položka "id" (malými písmeny) |
400 | bad-request | Request could not be recognized | Špatná struktura URL (mnoho lomítek), například https://localhost/unit/events/aaa/bbb/ccc |
401 | bad-password | Your name/password is invalid | Kombinace jména a hesla je neplatná, případně nedošlo k ověření certifikátu |
403 | not-authorized | You are not authorized | Uživatel není oprávněn k požadované operaci |
404 | not-found | Object not found | Je požadovaná špatná adresa, například https://localhost/nesmysl |
404 | not-found | ID not found | Adresa je platná, ale požadovaný objekt zadaného ID neexistuje |
405 | bad-request | Method not allowed | Požadovaná metoda (GET, POST, PUT nebo DELETE) není u této adresy přípustná, nebo není přípustné u dané adresy použít část events |
501 | not-implemented | Method not implemented | Není implementovaná požadovaná kombinace URL / GET |
Adresy jsou strukturované a až na vyjímky mají všechny adresy stejnou strukturu:
URL adresa pouze s názvem skupiny objektů (například pokoje - rooms) vrací kompletní seznam všech objektů dané třídy, například seznam pokojů:
URL adresa může mít různé parametry, které nějakým způsobem filtrují seznam, například offset a limit:
Vrací pole objektů:
Pokud se v URL adrese uvede ID objektu, vrátí se pouze vybraný objekt:
Vybraný objekt je vrácený samostatně, není součástí pole:
Přidáním řetězce events k cestě se vrátí proud událostí - hlásí se změny v celém seznamu. Na začátku se pošle jako samostatná událost každý objekt v seznamu, později se posílají pouze změny v tomto seznamu. Proud událostí se na serveru nezavírá, respektive je timeout pro uzavření proudu událostí řízený parametrem http/timeout.
Protože slovo events se přidává do URL adresy na místo, kde se běžně vyskytuje id objektu, nesmí mít žádný objekt id nastavené na events.
Vrací proud událostí, spojení se neuzavírá. Proud je v tomto dokumentu pro lepší čitelnost zformátovaný:
Pokud se uvede za ID požadovaného objektu slovo events, otevře se proud událostí spojený s tímto objektem. Události ostatních objektů stejného typu se nevypisují, jinak je formát stejný jako v případě proudu událostí v celém seznamu:
Proud událostí není podporovaný v prohlížeči MS Internet Explorer.
Pro zpracování na straně prohlížeče musí být podporovaný Javascript.
Typické zpracování událostí může vypadat například takto (Javascript + jQuery):
Pro zpracování proudu události existuje jednoduchá hotová knihovna: