[PHP] applicatie wel of niet via API laten communiceren?

[Tompouce]

Beste Tweakers,

Ik ben van plan om een behoorlijke webapplicatie te gaan maken in PHP (waarschijnlijk Laravel) . Ik ga hier een MySQL database bij gebruiken. Naast de webapplicatie wordt er een iPhone app voor gemaakt. Voor deze iPhone app gaan we een API maken, zodat de app kan communiceren via de API.

Mijn vraag is: zouden jullie de webapplicatie ook volledig via de API laten communiceren? Of niet? Dit is een behoorlijk essentiële keuze en ik ben benieuwd welke voor en nadelen het heeft. En wat jullie aanraden...

[WernerL]

Is volledig afhangkelijk van de front-end techniek die je gaat gebruiken. Ga je iets als AngularJS gebruiken en verloopt alle communicatie door middel van AJAX calls dan kun je van de back-end prima een REST-API maken.

[Barryvdh]

En of de webapplicatie grotendeels hetzelfde is. Als de app maar een klein deel van de functionaliteit heeft is het wellicht makkelijker om het met Laravel te maken, in plaats van overal een API voor maken.

[DennusB]

Ik zou het niet doen omdat je veel meer aan de front-end kant met Jquery en zo moet doen, niet alle (oude) browsers slikken dat even lekker.

[Barryvdh]

DennusB schreef op vrijdag 31 oktober 2014 @ 14:57:
Ik zou het niet doen omdat je veel meer aan de front-end kant met Jquery en zo moet doen, niet alle (oude) browsers slikken dat even lekker.

Ligt natuurlijk aan de applicatie, welke browser ondersteund moeten worden. En jQuery zorgt er juist voor dat het wel fatsoenlijk werkt op oude browsers.

[Gomez12]

Ik zou het bij een nieuw project in principe altijd via een API proberen te doen.

Ik zie bij mezelf steeds meer en meer dat er dingen cross-platform moeten en dat de cross-platforms toch nog net kleine dingetjes missen.
En dat ik ook aan de backend steeds meer / grotere systemen krijg.

Waardoor bijv een prog begonnen kan zijn met directe datatoegang voor php en een api voor de apps, maar dan moet daarna vanwege performance er een memcached oid tussengeschoven worden en die moet dan weer 2x ingevoegd worden. Oeps memcached voldoet niet en we moeten over naar redis (weer 2x wijzigen).

En het zoeken wat fulltext was voldoet ook niet, dus daar schuiven we een solr / sphinx tussen en weer 2x aanpassen.

Tegenwoordig ben ik meer van : ik schuif bijna overal een API tussenin en dan communiceert PHP ook maar met de API (oftewel je hoeft niet met een api direct angular oid te gaan gebruiken, je kan lekker door php'en alleen je dataretrieval doe je niet meer rechtstreeks)

[ZpAz]

Barryvdh schreef op vrijdag 31 oktober 2014 @ 15:20:
[...]

Ligt natuurlijk aan de applicatie, welke browser ondersteund moeten worden. En jQuery zorgt er juist voor dat het wel fatsoenlijk werkt op oude browsers.

Ik zou niet als je een complete website frontend via REST met een backend wil laten praten gaan voor jQuery maar eerder voor EmberJS of AngularJS.

Tegenwoordig ben ik meer van : ik schuif bijna overal een API tussenin en dan communiceert PHP ook maar met de API (oftewel je hoeft niet met een api direct angular oid te gaan gebruiken, je kan lekker door php'en alleen je dataretrieval doe je niet meer rechtstreeks)

Ik snap niet helemaal hoe je dat bedoelt. Ga je dan gewoon in je PHP code via iets als CURL de informatie opvragen van de API en parsen?

Je kan natuurlijk ook gewoon de correcte methode in je Controller aanroepen van je API. Dat zou wel werken inderdaad.

[ Voor 6% gewijzigd door ZpAz op 31-10-2014 21:42 ]

[Douweegbertje]

DennusB schreef op vrijdag 31 oktober 2014 @ 14:57:
Ik zou het niet doen omdat je veel meer aan de front-end kant met Jquery en zo moet doen, niet alle (oude) browsers slikken dat even lekker.

Dit is natuurlijk met alle respect ontzettende onzin Jquery heeft al support vanaf IE 6. Los daarvan ben je niet verplicht -alleen- jquery te gebruiken.

[Janoz]

Daarnaast zorgt het gebruiken van een API er niet voor dat de knip ook automatisch tussen de webserver en de browser meot liggen. Je kunt ook gewoon in je php code je api aanroepen.

[Rorata]

Je kan ook twee webapplicaties maken i.p.v een jquery oplossing. De api en de mvc waar in dit geval de m(odel) communiceert met de api en een controller en een view heeft.

Volgens mij heet dit multi tier architecture