Lizenzen und Sitzungen der RESTful Weg

Question

Diese Frage fiel mir ein, nachdem ich diesen Beitrag lesen: “Common REST Mistakes: Sessions are irrelevant”

Wenn Sitzungen sind in der Tat in einer RESTful Anwendung abgeraten. Wie würden Sie mit Lizenzen in einer solchen Anwendung umgehen? Ich beziehe mich speziell auf das Modell der gleichzeitigen Lizenzen und nicht auf die benannten Lizenzen. d.h. der Kunde kauft X-Lizenzen, was bedeutet, dass die Anwendung es erlauben kann, dass bis zu X Benutzer gleichzeitig angemeldet sind. Dies bedeutet, dass die Anwendung einen Status für aktuell angemeldete Benutzer enthalten muss.

Ich weiß, ich kann eine Ressource namens Lizenzen erstellen, die ein Cookie setzen oder eine eindeutige ID generieren, und dann muss der Client es mit jeder Anfrage senden. Aber es ist das Gleiche wie das Erstellen einer Sitzung, oder?

Wenn ich den statuslosen Ansatz anwende und den Client auffordere, ein Authentifizierungs-Token für jede Anfrage zu erstellen, wie weiß die Anwendung, wann sie die Lizenz für diesen Client nutzen und freigeben soll?

Gibt es eine Alternative? speziell eine mehr RESTful Alternative?

Answer 1

Lassen Sie mich versuchen, die Punkte für Sie zu verbinden, vorausgesetzt, ich interpretiere Ihre Frage richtig. Der von Ihnen gepostete Link hat eine gültige Antwort. Jede Anfrage sollte eine HTTP-Authentifizierung verwenden. Wenn Sie das Konzept von Lizenzen benötigen, um einen bestimmten Status für Ihren Benutzer beizubehalten, können Sie dies höchstwahrscheinlich mit dem Benutzer verknüpfen. Sie haben einen (verifizierten) Benutzernamen, um vorbei zu gehen. Sie müssen diesen Controller nur für jede Anforderung aufrufen und seinen Status speichern. Da hast du deine Sitzung.

Die Cookie-Eingabe sollte niemals für wichtige Informationen vertrauenswürdig sein, kann aber für die zusätzliche Überprüfung wie ein Sicherheitstoken sehr nützlich sein. Ich denke, das Hinzufügen eines zufälligen Sicherheits-Token-Felds zu Ihren Links vor Ort wäre der beruhigende Ansatz dafür. Es sollte natürlich mit der "Sitzung" ablaufen.

Answer 2

Sie sollten in Betracht ziehen, die Probleme der Lizenzverwaltung in den Infrastrukturstapel um eine Ebene zu verschieben. So ähnlich wie ein Aspect Oriented Programming (AOP) Ansatz, wenn Sie so wollen. Anstatt es möglicherweise in der Anwendungsebene zu behandeln, können Sie es in die Webserverebene verschieben.

Ohne die Details Ihrer Infrastruktur zu kennen, ist es schwierig, eine spezifische Empfehlung zu geben. Am Beispiel der Plattform * nix kann die Lizenzierungslogik als Modul für den Apache HTTP Server implementiert werden.

Dieser Ansatz fördert eine Trennung von Problemen in Ihrem Infrastruktur-Stack. Dadurch kann sich jede Ebene darauf konzentrieren, wozu sie gedacht ist. Die Anwendungsschicht muss sich überhaupt keine Gedanken über die Lizenzierung machen, sodass sie sich ausschließlich auf den Inhalt konzentrieren kann, was wiederum die URL sauber und "RESTful" hält.

Answer 3

Wenn Ihre Lizenzierung auf gleichzeitig angemeldeten Benutzern basiert, ist die Implementierung von HTTP Digest trivial und Sie können nur die maximale Anzahl gleichzeitiger Anmeldungen aktivieren. Der Digest verfügt über eine Funktion zum Übergeben von Ablaufdaten, sodass Ihre Sitzung ein Zeitlimit erreichen kann.

Authentifizierungsstatus wird von http Authentnication und nirgendwo sonst gehalten, weil es transparent und allgegenwärtig ist.

Answer 4

Vielleicht wäre eine REST-gestütztere Art, Lizenzen zu erstellen, die Geschwindigkeit, mit der Anfragen behandelt werden, und nicht die Anzahl der gleichzeitigen Sitzungen. Behalten Sie die Anzahl der Anfragen in der letzten Stunde im Auge, und wenn diese die vom Kunden bezahlte Anzahl überschreitet, senden Sie eine Antwort mit dem Betreff "503 Service Unavailable" zusammen mit einem Text, der darauf hinweist, dass der Nutzer es später erneut versuchen sollte.