RESTful API: Wo soll ich meinen Workflow programmieren?

Question

Ich entwickle eine RESTful API. Dies ist meine erste API, aber auch mein erstes wirklich großes Programmierprojekt. Als solche bin ich immer noch lernen viel über Architektur usw.

Derzeit habe ich meine api-Setup in den folgenden Schichten:

• HTTP-Layer
• Ressourcen Schicht
• Domain Model/Geschäfts Logic Layer-
• Data Access/Repository-Schicht
• Persistent Storage/DB-Schicht

Das Problem, auf das ich im Moment gestoßen bin, ist wo muss ich Arbeitsablaufobjekte/Manager setzen? Unter Workflows verstehe ich Code, der den nächsten Schritt für den Endbenutzer bewertet. Zum Beispiel ein E-Commerce-Workflow. Der Benutzer fügt Artikel in den Warenkorb ein, checkt dann aus, fügt dann persönliche Daten ein und zahlt dann. Der Workflow wäre verantwortlich für die Entscheidung, welche Schritte als nächstes ausgeführt werden, aber auch welche Schritte NICHT erlaubt sind. Beispielsweise könnte ein Benutzer keine Fehler in der API verursachen, indem er versucht, zu zahlen, bevor er persönliche Daten eingegeben hat (vielleicht rufen sie die URI für Zahlungen zurück und versuchen, einen Schritt zu überspringen). Der Workflow würde prüfen, ob alle vorherigen Schritte abgeschlossen wurden, andernfalls würde die Zahlung nicht möglich sein.

Derzeit befindet sich meine Workflow-Logik in der Ressourcenschicht. Ich verwende Hypermedia-Links, um den Workflow dem Benutzer z. Bereitstellung eines "Next Step" -Links. Das Problem dabei ist, dass die Ressourcenebene eine Ebene der obersten Ebene und mehr mit der Präsentation ausgerichtet ist. Ich denke, dass es zu viel über das zugrundeliegende Domänenmodell wissen muss, um einen Workflow effektiv zu bewerten, d. H. Es müsste wissen, dass es die Einheit personal_detail prüfen muss, bevor es die Zahlung erlaubt.

Dies führt mich zu der Annahme, dass Workflows in das Domänenmodell gehören. Das macht viel mehr Sinn, da wirklich Workflows Teil der Geschäftslogik sind und ich denke, dass sie daher am besten in der Domänenebene platziert sind. Ersetzen Sie den Ressourcen-Layer durch etwas anderes, und Sie benötigen weiterhin die zugrunde liegenden Workflows.

Nun aber besteht das Problem darin, dass Workflows das Wissen mehrerer Domänenobjekte benötigen, um ihre Logik zu vervollständigen. Es fühlt sich jetzt richtig an, dass es vielleicht in eine eigene Schicht geht? Zwischen Ressourcen- und Domänenebene?

• HTTP-Layer
• Ressourcen Schicht
• Workflow-Schicht
• Domain Model/Business-Logik-Schicht
• Data Access/Repository-Schicht
• Persistent Storage/DB-Schicht

Ich frage mich nur ob Hatte jemand andere Ansichten oder Gedanken dazu? Wie gesagt, ich habe keine Erfahrung in der Vergangenheit, um zu wissen, wo Workflows platziert werden sollten. Ich lerne das wirklich zum ersten Mal und möchte sicherstellen, dass ich den richtigen Weg gehe.

Links zu Artikeln oder Blogs, die dies abdecken, würden sehr geschätzt werden. Liebe, die auf verschiedenen Implementierungen liest.

EDIT

Um zu klären, ich loslassen, dass HATEOAS der Client ermöglicht durch den ‚Workflow‘ zu navigieren, aber es muss etwas in meinem API sein, der weiß, was das heißt es wirklich zu zeigen, verknüpft wird, um den Workflow definiert, ist dürfen. Es stellt Workflow-bezogene Links in der Ressource bereit, validiert jedoch zusätzlich Anforderungen, die mit dem Workflow übereinstimmen. Während ich zustimme, dass ein Kunde wahrscheinlich nur den in der Ressource bereitgestellten Links folgt, ist die Gefahr (und Schönheit) der Ruhe, dass seine URI getrieben wird, so dass nichts einen schelmischen Kunden daran hindert, Schritte im Arbeitsablauf zu "überspringen" eine fundierte Vermutung über die URI machen. Die API muss dies erkennen und eine 302-Antwort zurückgeben.

Answer 1

Die Antwort auf diese Frage hat mich ein wenig Forschung gekostet, aber im Grunde hat der 'Workflow' Teil nichts mit REST zu tun und mehr mit der Anwendungsschicht zu tun.

Mein System hatte die Anwendungslogik und REST API zu eng gekoppelt. Ich löste mein Problem durch Refactoring, um die Kopplung zu reduzieren und jetzt lebt der Workflow im Kontext der Anwendung

Answer 2

REST ermutigt Sie, ein Vokabular von Substantiven (Benutzer, Produkte, Einkaufswagen) gegen eine etablierte Gruppe von Verben (GET, POST, PUT, DELETE) zu erstellen. Wenn Sie sich an diese Regel halten, wird in Ihrem Beispiel der Workflow wirklich durch die Menge der Interaktionen definiert, die der Benutzer mit Ihrer Site hat. So nutzt der Nutzer Ihre App, die wirklich von der Benutzeroberfläche definiert wird. Ihre REST-Dienste sollten angemessen auf ungültige Statusanforderungen reagieren, z. B. wenn Sie versuchen, mit einem leeren Einkaufswagen auszuchecken. Die Benutzeroberfläche kann jedoch auch solche Anfragen mithilfe von Skript verhindern, was ein optionales Merkmal von REST ist.

Zum Beispiel kann die Benutzeroberfläche, die ein Produkt für den Benutzer anzeigt, auch einen Link anzeigen, der es dem Benutzer erlauben würde, dieses Produkt zu seinem Warenkorb hinzuzufügen (POST shoppingcart/{productId}). Der Server sollte sich wirklich nicht darum kümmern, wie der Benutzer zu diesem POST gelangt ist, nur dass er das Produkt dem Warenkorb des Benutzers hinzufügen und eine aktualisierte Darstellung des Einkaufswagens an den Benutzer zurückgeben soll. Die Benutzeroberfläche kann dann JavaScript verwenden, um zu bestimmen, ob ein Link zur Kasse angezeigt werden soll oder nicht, nur wenn der Warenkorb über ein oder mehrere Elemente verfügt.

Es scheint also, dass Ihr Workflow außerhalb des REST-Service liegt und eher durch die Navigation in Ihren Seiten definiert wird, die mit Ihren REST-Services interagieren, wenn der Benutzer Dinge anfordert. Es ist sicherlich möglich, dass Sie interne Workflows haben, die in Ihrer Anwendung basierend auf den vom Benutzer eingerichteten Status auftreten müssen. Was Sie jedoch zu beschreiben scheinen, ist eine Benutzerinteraktion innerhalb der Website. Obwohl dies in der Tat ein Workflow ist, scheint er von Ihren Benutzeroberflächen besser definiert zu sein als von einer dedizierten serverseitigen Komponente/Schicht.

Answer 3

Sie möchten möglicherweise Ihre Architektur entlang der Linien von DDD (Domain Driven Design) neu ausrichten und vielleicht ein MSA verwenden, Auf diese Weise können Sie vom orchestrierten Workflow zur EDA und Choreografie von Mikroprozessen übergehen.

Answer 4

Sie berühren den Workflow (auch Business Logic) Teil einer API. Technisch ist dies ein separates Anliegen gegenüber dem API-Teil, der die Schnittstelle darstellt. Sicher, wie Sie erwähnen, erlaubt HATEOAS Ihnen, bestimmte Aktionen vorzuschlagen, die gültig sind, aber Sie sollten vorsichtig sein, statelessness aufrechtzuerhalten.

In REST-Anwendungen darf auf der Serverseite kein Sitzungszustand gespeichert sein. Stattdessen muss es vollständig vom Client gehandhabt werden.

Wenn also Sitzungsstatus auf dem Server ist, ist es nicht REST.

Für Ihr Einkaufswagen-Beispiel können Sie den Status in einer separaten Caching-Ebene wie Redis speichern.Wie für Ihre Arbeitsabläufe. Sie möchten keine Geschäftslogik wie das Berechnen von Einkaufswagen oder Gesamtkosten in ein Domänenmodell einfügen. Dies würde zur Serviceebene hinzugefügt werden.

Sie sprachen über schelmische Benutzer, die URLs erraten. Dies ist immer ein Anliegen und sollte von Ihrer Sicherheit behandelt werden. Wenn die URL zum Löschen eines Benutzers DELETE ist, können sie leicht erraten, wie alle Benutzer gelöscht werden. Aber Sie sollten sich nicht nur darauf verlassen, die URLs zu verschleiern. Sie sollten in Ihren Endpunkten echte Sicherheits- und Zugriffsprüfungen durchführen, um zu prüfen, ob jede Anfrage gültig ist.

Dies ist die gleiche Lösung für Ihre Einkaufswagen Bedenken Sie müssen ein Token gewähren, das ihre Einkaufsinformationen anhängen und diese verwenden, um jede Aktion zu validieren, unabhängig davon, ob sie die richtige URL kennen oder nicht. Es gibt keine Abkürzungen, wenn es um Sicherheit geht.