MsGuru01 schrieb am 02.08.2019 14:16:
Rest APIs hingegen, haben nicht einzentral Endpunkt, sonder die API selber ist eine URL zur angefragten resourcen a la https://example.com/api/users um alle user abzufragen (oder neue hinzuzufügen), weil "users" hier die resource ist (plural, also viele). Während hingegen https://example.com/api/users/1 die URL zu einer speziellen Resource ist, nähmlich dem User mit der user ID 1.
Das dieses Konzept aber auch nicht für alle Anforderungen sooo super gut ist, sieht man im aktuell hart trendenden GraphQL. Da gibt es wieder eine Reduktion der HTTP-Methoden und der Endpunkte und dafür eine Parametrisierung der Datenstruktur, wodurch Viel unnötiger Datenaustausch vermieden und Abfragen zusammengefasst werden können.
MsGuru01 schrieb am 02.08.2019 14:16:
Dieses reiht sich auch viel besser mit der Idee von Microservices ein, wo die Dienste in viele kleine Dienste aufgeteilt werden. Jeder der Microservices kann seaprat versioniert werden. Will man z.B. die users API aktualisieren, stellt man einfach die neue Version des Dienstes unter https://example.com/api/v2/users zur verfügung, während die alte weiterhin auf https://example.com/api/users oder https://example.com/api/v1/users erreichbar ist.
Neueste Microsoervice-Architekturen verwenden vermehrt REST und GraphQL. Kommt immer auf den Einsatzzweck drauf an. Beide haben so ihre Stärken und schwächen und das schöne ist, dass das eine seine Stärken dort hat, wo das andere seine Schwächen hat. Dadurch ergänzt sich das sehr gut.