Quote (Prophets @ 2 May 2016 21:52)
api - stateful (wie mein charf es gern hätte) oder stateless (wie ich es machen werde)
mein chef hat mir heute beim entwerfen der db immer "das macht das framework dann alles in sessions" "aber du musst nirgends ein token extra speichern, macht doch alles die session" etc an den kopf geworfen.
Ich bin fest davon überzeugt das eine API nicht stateful ist und das user sich mit jeder anfrage via token authentifizieren sollten.
die app die die api befeuern soll wird später etwa in der größe von .. nike running/fitnesstrackern o.ä, sein, also kein 2. facebook aber auch nicht nur ein request alle paar minuten.
wer von euch hat ahnung im api design, sowas schonmal produktiv gemacht und kann mir vor- und nachteile von stateless und stateful kurz näher bringen? Ja, gegoogelt habe Ich freilich, finde da jedoch kontroverses kram und weiss nicht wem ich glauben soll.
vielleicht bin ich auch einfach absolut voreingenommen.
sprich mal jemand tacheles mit mir mir, bitte.
ob/wie das ganze serverseitig skaliert/verteilt wird steht nochnicht fest, die hardware wird erst noch bereitgestellt. Ist das von der wichtigkeit her eher weit oben bei der entscheidung ob ful oder less, oder eher egal?
aso, das ganze wird in php mit laravel gebaut. db wird ne stinknormale mysql.
für payloads wollte ich json nehmen.
Stateless APIs sind auf jeden Fall die Mode. I.d.R. will man REST und die standard HTTP Methoden benutzen. Insofern hast du auf jeden Fall, die aktuelle dev Hipster Meinung auf deiner Seite
Ich bin bei dem Thema leider auch kein Experte, aber ich kann ja mal sagen, was aus meiner Sicht die pro und contras sind.
RESTful / stateless APIs sind praktisch ein Standard. Diese werden nicht vom end user gerufen, sndern eben von einer client application. Diese clients (sei es mobile, sei es javascript, sei es ein B2B Fremsystem) betreiben dann durchaus Session management. Bei jedem HTTPRequest werden credentials mitgeschickt. Das ist, wie ich das verstehe, auch das was du willst. Die Vorteile sind vor allem, dass die API wirklich eine API ist und clients viel Freiheit überlässt. Das, woran man heute denkt, wenn man API hört, ist eigentlich wirklich i.d.R. stateless.
Der Nachteil ist eine gute Mischung aus security und efficiency zu finden. Bei jedem Request wird eben neu authentifiziert. Außerdem müssen jede Menge Daten mitgeschickt werden. Klar, werden IDs übergeben und zu denen liegen zusätzliche Informationen auf backend Seite vor. Trotzdem wäre Einstellungen, wie man sie typischer Weise in cookies sichert wohl eher von der Art, dass sie jedesmal mitgeschickt werden. Gerade wenn man also eigentlich eifnach ein Interface zwischen einem eigenen backend und client baut, kann man sich einiges ersparen, wenn man eben NICHT extra eine "API" macht sondern einfach eine stateful Schnittstelle. Und ganz eigentlich, ist das auch eine API (Application Programming Interface).
Würde also sagen es kommt in eurem Fall darauf an, ob es eine öffentliche API (dann stateless) oder eine nicht-öffentliche (dann kann beides sinnvoll sein und man muss Flexibilität gegen Effizienz und convenience abweigen) für bekannte clients ist.
Wenn aber wirklich z.b. jede Hinz-und-Kunz developer eine App machen können soll, die eure API nutzt, dann sollte die wirklich stateless sein.
Zu oft wird aber mit einer imaginären Zukunft für die Programme noch-so-flexibel sein müssen argumentiert und man wasted ewig viel Zeit um für Fälle, die eh nie eintreten Vorsorge zu treiben.
Aber nochmal: Ich bin echt kein Web Egsperte
Sind nur meine 2 cent
This post was edited by Kasiir on May 3 2016 02:11am