Jak rozumně doplnit API do aplikace?
- kuncajs
- Člen | 11
Ahoj,
konečně jsme se odhodlali přejít na Nette 2 a v rámci toho bychom chtěli
přidat JSONovou API, protože chceme vyvíjet nativní Android aplikaci.
V rámci toho jsme měli dva nápady a chtěl bych se zeptat, co si o tom myslíte.
1. API udělat tak, že vezmeme veškeré routy existující aplikace a
podle nějakého atributu (parametru v URL, mimetypu apod.) vzít obsah
atributu template v daném presenteru a převést obsah na JSON data.
Výhody: Využijeme existující presentery a pouze změníme
view, šablonu a daná data zobrazím jinak (místo HTML, jako JSON objekt), a
velkou rychlost implementace, protože by zřejmě stačilo změnit
BasePresenter tak, aby dělal, co má.
Nevýhody Asi tak trošku hack? Jak rozpoznat, že data
v templatu už jsou správně nachystaná? API je kompletně závislé na
architektuře webové aplikace, pokud se stane, že mobilní aplikace bude mít
jiné úkoly možná se to bude dělat méně snadno. $presenter->template
má v sobě spoustu dalšího „bordýlku“ než jen uživatelské atributy a
tyto atributy nedrží v žádném namespacu, takže je těžké je od
ostatního obsahu oddělit.
2. Udělat aplikaci RESTful (případně WS) tak, že kompletně oddělíme
současnou aplikaci a API. Vytvoříme API pro jednotlivé entity a BO a nad
nimi případně nějaké služby atd.
Výhody Čisté řešení, oddělení API, takže se vyhneme
problémům, rozšiřitelné do budoucna, existující standard, takže
napojení na jiné služby či poskytování služeb námi bude
jednodušší.
Nevýhody Pracnější, „všechno 2x“, nevyužívá už
existující presentery, kde stačí zobrazit načtená data pouze jinak
(JSON/XML místo HTML).
Co si o tom myslíte? Případně máte ještě jiné, elegantnější řešení? Díky!
- David Ďurika
- Člen | 328
preve riesim podobnu vec! a budem to riesit 2. sposobom co sa tyka tej nevihody, tak to by namalo byt az tak zle ako pises, kedze v presentry ma byt len uplne jednoducha logika… ano bude 2× ale inak to asi nepojde…
mna by este zaujimalo ako riesit bezpecnost? aby nemal hocikto pristup k datam atd.
- Felix
- Nette Core | 1270
Druhy zpusob je urcite lepsi a spravnejsi nez ten prvni. API krasne napojis na servisni vrstvu, kde bys mel mit veskery validace a tim padem ti je jedno jestli to pak pouzijes v presenteru nebo v API – at REST ci cokoli jinyho.
achtan napsal(a):
mna by este zaujimalo ako riesit bezpecnost? aby nemal hocikto pristup k datam atd.
Token, oauth, jakakoli autorizace…
- newPOPE
- Člen | 648
@kuncajs – ked by si si pozrel RoR (Railsy) tie to maju tak nejak urobene.
Oni vedia servirovat obsah podla hlavicky Accept (aspon tak sa mi zdalo) a bud ide JSON alebo HTML.
Cize ked chodis z browsera tak zobrazuju tabulky, formulare na
editaciu…
Ked ides REST-om tak servuju JSON-y. Vcelku luxusne riesenie.
Editoval newPOPE (25. 6. 2013 17:16)
- llook
- Člen | 407
Ten Rails přístup může být dobrý pro nějaké prototypování (jiný výraz pro bastlení), ale pokud jde o něco aspoň trochu složitějšího, tak to už tak luxusní být nemusí. Narazíš už když budeš chtít různě podrobný obsah pro různá zařízení, nebo trochu jinak strukturovaný.
Šel bych spíš druhou cestou. Pokud to API děláš jenom pro svoji aplikaci, tak může růst postupně s tou aplikací a pěkně na míru.