Rest API¶

• offline mobilní aplikace
• při připojení k internetu bude posílat dosažené výsledky a stahovat nové úlohy a balíky přidělené terapeutem
• potřeba navrhnout a implementovat Rest API, se kterým bude moct aplikace komunikovat

---

Odesílání souborů přes Rest API¶

• po analýze bylo zjištěno a nalezena 2 řešení, která by byla možná implementovat
• potřeba probrat s M. Horkým na nějaké schůzce, které řešení se zvolí, zda by bylo potřeba řešit úplně jinak

1. Řetězec v Base64¶

• Base64 je kódování, které převádí binární data na posloupnosti tisknutelných znaků.
• umožňuje přenos binárních dat kanály, které dovolují pouze přenos textů.
• Výhody:
  • funguje na jakákoliv binární data (obrázky, soubory, ...)
  • velice jednoduchá implementace v C#
• Nevýhody
  • největší nevýhodou tohoto řešení je, že velikost vytvořeného/odesílaného řetězce je zhruba o 20-30% větší

2. Komprimované Base64¶

• nevýhodu prvního řešení lze odstranit nějakou kompresí (Gzip, DeflateStream, ...)
• podle zvolené komprese by se sice ztrácela kvalita obrázků, ale přenos dat by se mohl zrychlit, protože velikost dat by měla být menší
  • nechceme aby stahování/odesílání trvalo příliš dlouho (pacient může trénovat pouze po dobu jedné hry, či pouze zkoumat dosažené výsledky)
• řešení by fungovalo tak, že by se
  • zapnula aplikace a zahájilo se tak stahování/odesílání potřebného obsahu
  • mobilní aplikace by přijala komprimovaný obrázek v base 64 formátu

• pokud by byla potřeba stejná kvalita obrázků, jak v aplikace tak v systému byla by možnost spolu s komprimovaným obrázkem posílat i url
  • url by obsahovala adresu, kde by se nacházel soubor v plné kvalitě
  • po stažení všech potřebných/nových dat ze systému by se na pozadí aplikace zahájilo stahování obrázků v plné kvalitě a nenarušovalo uživatele

3. Použít multipart/from-data namísto JSONu¶

• POST a PUT metody jsou RESTFull, jak jen to jde
  • obsahují textový vstup společně se soubory
• nevýhodou je, že přenos už nebude realizovaný pomocí JSONu, který je daleko jednodušší k testování, ladění, ...

Podle mého názoru by bylo nejlepší buď první řešení, pokud nebude zákazníkovi vadit delší stahování (případně zvolit řešení č. 2)

Autorizace přeš API¶

• vhodné přes autorizační token získaný při přihlášení s omezenou platností
  • potřeba ujasnit u zákazníka (na předchozí schůzce zmiňoval, že ještě upřesní své požadavky)

Navrhované endpointy¶

• podoba endpointů bude vytvořena po zhodnocení nároků a vlastností mobilní aplikace pro kterou API vzniká.