Jak rozumně doplnit API do aplikace?

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
kuncajs
Člen | 11
+
0
-

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
+
0
-

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
+
0
-

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
+
0
-

@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
+
0
-

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.