Verschiedene Konzepte im Zusammenhang mit REST-Konflikten treten in meinem Kopf auf, wenn ich versuche, sie zu implementieren.
Ich habe ein REST-volles Back-End-API-System, das die Geschäftslogik enthält, und eine Webanwendung, die die Benutzeroberfläche bereitstellt. Aus verschiedenen Quellen zu REST (insbesondere REST in der Praxis: Hypermedien und Systemarchitektur ) weiß ich, dass ich keine unformatierten Bezeichner meiner Entitäten offen legen, sondern Hyperlinks mit zurückgeben sollte rel="self".
Betrachten Sie das Beispiel. Die REST-API verfügt über eine Ressource, die eine Person zurückgibt:
<Person>
<Links>
<Link rel="self" href="http://my.rest.api/api/person/1234"/>
</Links>
<Pets>
<Link rel="pet" href="http://my.rest.api/api/pet/678"/>
</Pets>
</Person>
Das Problem tritt bei der Webanwendung auf. Angenommen, es wird eine Seite zurückgegeben, die einen Hyperlink zu Browsern enthält:
<body class="person">
<p>
<a href="http://my.web.app/pet/???????" />
</p>
</body>
Was soll ich in das hrefAttribut setzen? Wie behalte ich die URL der API-Entität in der Webanwendung, um die Entität abzurufen, wenn ein Benutzer die Zielseite öffnet?
Die Anforderungen scheinen sich zu widersprechen:
- Der Hyperlink
hrefsollte zur Webanwendung führen, da dies das System ist, auf dem die Benutzeroberfläche gehostet wird - Die
hrefsollte eine ID der Entität haben, da die Web-App in der Lage sein muss, die Entität zu adressieren, wenn die Zielseite geöffnet wird - Die Web-App sollte keine REST-URLs parsen / konstruieren, da diese nicht REST-voll sind, heißt es in dem genannten Buch
URIs sollten für Verbraucher undurchsichtig sein. Nur der Emittent des URI kann ihn interpretieren und einer Ressource zuordnen.
Ich kann also nicht einfach 1234die API-Antwort-URL auslesen, da ich sie als RESTful-Client so behandeln sollte, als wäre sie so etwas wie http://my.rest.api/api/AGRIDd~ryPQZ^$RjEL0j. Andererseits muss ich eine URL angeben, die zu meiner Web-App führt und ausreicht, damit die App die ursprüngliche URL der API wiederherstellt und diese URL für den Zugriff auf die API-Ressourcen verwendet.
Am einfachsten ist es wahrscheinlich, die API-URLs von Ressourcen als Zeichenfolgen-IDs zu verwenden. Aber Webseiten-URLs wie http://my.web.app/person/http%3A%2F%2Fmy.rest.api%2Fapi%2Fperson%2F1234sind hässlich.
Für eine Desktop-App oder eine Single-Page-Javascript-App scheint alles ganz einfach zu sein. Da sie ununterbrochen leben, können sie die URLs nur zusammen mit den Serviceobjekten für die Anwendungslebensdauer im Speicher behalten und sie bei Bedarf verwenden.
Mit einer Web-App kann ich mir mehrere Ansätze vorstellen, aber alle scheinen komisch:
- Ersetzen Sie den Host in den API-URLs und behalten Sie nur das Ergebnis bei. Der große Nachteil ist, dass die Webanwendung die URL verarbeiten muss, die von der API generiert wird, was eine monströse Kopplung bedeutet. Darüber hinaus ist es nicht wieder RESTful, weil meine Web-App beginnt, die URLs zu interpretieren.
- Stellen Sie die Roh-IDs in der REST-API zusammen mit den Links bereit, erstellen Sie daraus die URLs der Webanwendung und ermitteln Sie anhand der IDs auf dem Webanwendungsserver die erforderlichen Ressourcen in der API. Dies ist besser, wirkt sich jedoch auf die Leistung des Webanwendungsservers aus, da die Webanwendung die REST-Dienstnavigation durchlaufen muss, um eine Kette von Get-by-ID-Anforderungen in irgendeiner Form auszugeben, um alle Anforderungen eines Browsers zu verarbeiten. Für eine etwas verschachtelte Ressource kann dies kostspielig sein.
- Speichern Sie alle
selfvom API zurückgegebenen URLs in einer permanenten Zuordnung (DB?) Auf dem Webanwendungsserver. Generieren Sie einige IDs für diese, erstellen Sie mithilfe der IDs die URLs der Webanwendungsseite und rufen Sie die URLs der REST-Serviceressourcen ab. Dh ich behalte diehttp://my.rest.api/pet/678URL irgendwo mit einem neuen Schlüssel, z. B.3und generiere die Webseiten-URL alshttp://my.web.app/pet/3. Dies sieht aus wie eine Art HTTP-Cache-Implementierung. Ich weiß nicht warum, aber es kommt mir komisch vor.
Oder bedeutet dies alles, dass RESTful-APIs nicht als Back-End für Webanwendungen dienen können?