Rest API » Historie » Verze 4
Daniel Wébr, 2022-03-14 09:29
1 | 1 | Vojtěch Váchal | h1. Rest API |
---|---|---|---|
2 | |||
3 | * offline mobilní aplikace |
||
4 | * při připojení k internetu bude posílat dosažené výsledky a stahovat nové úlohy a balíky přidělené terapeutem |
||
5 | * potřeba navrhnout a implementovat Rest API, se kterým bude moct aplikace komunikovat |
||
6 | |||
7 | ---- |
||
8 | |||
9 | 3 | Vojtěch Váchal | h3. Odesílání souborů přes Rest API |
10 | 1 | Vojtěch Váchal | |
11 | * po analýze bylo zjištěno a nalezena 2 řešení, která by byla možná implementovat |
||
12 | * 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 |
||
13 | |||
14 | 2 | Vojtěch Váchal | h4. 1. Řetězec v Base64 |
15 | 1 | Vojtěch Váchal | |
16 | * Base64 je kódování, které převádí binární data na posloupnosti tisknutelných znaků. |
||
17 | * umožňuje přenos binárních dat kanály, které dovolují pouze přenos textů. |
||
18 | * Výhody: |
||
19 | ** funguje na jakákoliv binární data (obrázky, soubory, ...) |
||
20 | ** velice jednoduchá implementace v C# |
||
21 | * Nevýhody |
||
22 | ** 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ší |
||
23 | |||
24 | 2 | Vojtěch Váchal | h4. 2. Komprimované Base64 |
25 | 1 | Vojtěch Váchal | |
26 | * nevýhodu prvního řešení lze odstranit nějakou kompresí (Gzip, DeflateStream, ...) |
||
27 | * 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ší |
||
28 | ** 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) |
||
29 | * řešení by fungovalo tak, že by se |
||
30 | ** zapnula aplikace a zahájilo se tak stahování/odesílání potřebného obsahu |
||
31 | ** mobilní aplikace by přijala komprimovaný obrázek v base 64 formátu |
||
32 | |||
33 | * 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 |
||
34 | ** url by obsahovala adresu, kde by se nacházel soubor v plné kvalitě |
||
35 | ** 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 |
||
36 | |||
37 | 2 | Vojtěch Váchal | h4. 3. Použít multipart/from-data namísto JSONu |
38 | 1 | Vojtěch Váchal | |
39 | * POST a PUT metody jsou RESTFull, jak jen to jde |
||
40 | ** obsahují textový vstup společně se soubory |
||
41 | * nevýhodou je, že přenos už nebude realizovaný pomocí JSONu, který je daleko jednodušší k testování, ladění, ... |
||
42 | 2 | Vojtěch Váchal | |
43 | 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) |
||
44 | 4 | Daniel Wébr | |
45 | h3. Autorizace přeš API |
||
46 | * vhodné přes autorizační token získaný při přihlášení s omezenou platností |
||
47 | ** potřeba ujasnit u zákazníka (na předchozí schůzce zmiňoval, že ještě upřesní své požadavky) |
||
48 | |||
49 | h3. Navrhované endpointy |
||
50 | * podoba endpointů bude vytvořena po zhodnocení nároků a vlastností mobilní aplikace pro kterou API vzniká. |