Rest API » Historie » Revize 6
Revize 5 (Daniel Wébr, 2022-03-14 09:29) → Revize 6/28 (Daniel Wébr, 2022-03-14 09:29)
h1. 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 ---- h3. 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 h4. 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ší h4. 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 h4. 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) h3. 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) h3. Navrhované endpointy * podoba endpointů bude vytvořena po zhodnocení nároků a vlastností mobilní aplikace pro kterou API vzniká vzniká.