Commit 6089aae6 authored by Jens Ehlers's avatar Jens Ehlers
Browse files

fixed typo

parent 2d499d76
Pipeline #15430 passed with stage
in 1 minute and 16 seconds
......@@ -126,7 +126,7 @@ Der prinzipielle Ablauf der Kommunikation zwischen Client und Server ist in der
Weitere Konventionen eines REST-Webservice sind:
<ul>
<li><b>Cachebarkeit</b>: Der lesende Zugriff mittels GET ist seitenfrei, d.h. der Zustand keiner Ressource wird verändert. Dadurch können Clients und Intermediäre (Proxys) die Antworten auf GET-Anfragen cachen, solange dieses nicht explizit durch einen entsprechenden Eintrag im HTTP-Header (<a href="https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Cache-Control">Cache-Control</a>) unterbunden wird. Das Caching kann die Performance der Anwendung verbessern und eingeschränkte Offline-Funktionalität ermöglichen.</li>
<li><b>Cachebarkeit</b>: Der lesende Zugriff mittels GET ist seiteneffektfrei, d.h. der Zustand keiner Ressource wird verändert. Dadurch können Clients und Intermediäre (Proxys) die Antworten auf GET-Anfragen cachen, solange dieses nicht explizit durch einen entsprechenden Eintrag im HTTP-Header (<a href="https://developer.mozilla.org/de/docs/Web/HTTP/Headers/Cache-Control">Cache-Control</a>) unterbunden wird. Das Caching kann die Performance der Anwendung verbessern und eingeschränkte Offline-Funktionalität ermöglichen.</li>
<li><b>Idempotenz:</b> Zugriffe auf eine Ressource per GET, PUT und DELETE sind idempotent, d.h. wenn mehrere Zugriffe hintereinander mit den gleichen Parametern ausgeführt werden, ist der serverseitige Zustand derselbe wie bei einem einzelnen Zugriff. Idempotenz erleichtert die Fehlertoleranz, da ein Client im Zweifel, wenn er unsicher ist, ob eine GET-, PUT- oder DELETE-Anfrage den Server erreicht hat, diese Anfrage einfach wiederholen kann. Für POST- und PATCH-Anfragen wird per Konvention keine Idempotenz gefordert.</li>
<li><b>Zustandslosigkeit</b>: Bei einem REST-Webservice ist die Client-Server-Kommunikation grundsätzlich zustandslos, d.h. der Server speichert keinen Kontext des Client zwischen dessen einzelnen HTTP-Requests. Es gibt also serverseitig keine <i>Sessions</i>. Das schließt allerdings nicht aus, dass sämtliche HTTP-Requests vom Server in einer Logdatei protokolliert werden. Jeder Client muss nun selbst den Zustand seiner Session vorhalten und bei jedem HTTP-Request ggf. ein Token zur Autorisierung an den Server mitsenden, falls dieses für den Zugriff auf eine geschützte Ressource erforderlich ist. Demzufolge gibt es i.d.R. als Teil eines REST-Webservice eine bestimmte Ressource zur Authentifizierung, bei der ein Client initial ein entsprechendes Token erhalten kann. Weiter unten gehen wir zu diesem Zweck genauer auf <a href="https://jwt.io/">JSON Web Tokens (JWT)</a> ein </li>
</ul>
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment