Webservices und Client Server Konzepte - Versionsgeschichte

Drlue: /* Mögliche Implementierung */

2021-02-23T17:11:02Z

Mögliche Implementierung

← Nächstältere Version		Version vom 23. Februar 2021, 17:11 Uhr
Zeile 149:		Zeile 149:
	Eine Rechenauslastung auf Seiten des Servers findet jedoch nicht statt. Der '''Body''' der Antwort muss bei jeder Antwort erstellt werden um den '''ETag''' zu generieren. Das bedeutet, der Server muss trotzdem Anfragen an die Datenbank stellen bzw. alle nötigen Berechnungen ausführen um die Antwort zu erstellen.		Eine Rechenauslastung auf Seiten des Servers findet jedoch nicht statt. Der '''Body''' der Antwort muss bei jeder Antwort erstellt werden um den '''ETag''' zu generieren. Das bedeutet, der Server muss trotzdem Anfragen an die Datenbank stellen bzw. alle nötigen Berechnungen ausführen um die Antwort zu erstellen.
	<br>		<br>
	Weiters ist das Bilden der Hashsumme, vorallem wenn es sich um größere Datenmengen handelt, eine rechenintensive Operation. Ändern sich die Daten regelmäßig, so könnte man sich das bilden der '''Hashsumme''' und den daraus resultierenden Mehraufwand, sparen.		Weiters ist das Bilden der '''Hashsumme''', vorallem wenn es sich um größere Datenmengen handelt, eine rechenintensive Operation. Ändern sich die Daten regelmäßig, so könnte man sich das bilden der '''Hashsumme''' und den daraus resultierenden Mehraufwand, sparen.

	=== Zustandslosigkeit ===		=== Zustandslosigkeit ===

Drlue: /* Caching */

2021-02-23T17:10:36Z

Caching

← Nächstältere Version		Version vom 23. Februar 2021, 17:10 Uhr
Zeile 84:		Zeile 84:
	'''{{AL\|HTTP}} Caching''' soll implementiert werden. '''Wobei jede Anfrage die nicht gestellt werden muss, die beste ist.'''		'''{{AL\|HTTP}} Caching''' soll implementiert werden. '''Wobei jede Anfrage die nicht gestellt werden muss, die beste ist.'''
	Klären wir zuerst den Begriff des '''Cachings'''. Dieses Konzept gilt natürlich in vielen Bereichen der Informatik, wir erklären den Begriff anhand des Zugriffs auf eine '''Ressource'''. Eine '''Ressource''' wird geholt, zu einem späteren Zeitpunkt wird diese '''Ressource''' erneut geholt. Hat sich diese nicht verändert, so soll sie nicht erneut übertragen werden, sondern aus dem Zwischenspeicher der Anwendung abgerufen werden.<br>		Klären wir zuerst den Begriff des '''Cachings'''. Dieses Konzept gilt natürlich in vielen Bereichen der Informatik, wir erklären den Begriff anhand des Zugriffs auf eine '''Ressource'''. Eine '''Ressource''' wird geholt, zu einem späteren Zeitpunkt wird diese '''Ressource''' erneut geholt. Hat sich diese nicht verändert, so soll sie nicht erneut übertragen werden, sondern aus dem Zwischenspeicher der Anwendung abgerufen werden.<br>
	Durch Caching bei Webanwendungen soll die Übertragung von Daten über das Internet reduziert werden.		Durch '''Caching''' bei Webanwendungen soll die Übertragung von Daten über das Internet reduziert werden.
	In folgender Tabelle wird die Funktionsweise von '''{{AL\|HTTP}} Caching''' mittels '''ETag''' beschrieben. Man beachte, die {{AL\|HTTP}} Anfragen sind '''nicht''' vollständig und beschränken sich auf die fürs '''Caching''' wesentlichen {{AL\|HTTP\|HTTP Header}}.		In folgender Tabelle wird die Funktionsweise von '''{{AL\|HTTP}} Caching''' mittels '''ETag''' beschrieben. Man beachte, die {{AL\|HTTP}} Anfragen sind '''nicht''' vollständig und beschränken sich auf die fürs '''Caching''' wesentlichen {{AL\|HTTP\|HTTP Header}}.
	{\| class="wikitable"		{\| class="wikitable"

Drlue: /* Lösung über Session und Cookie */

2021-02-15T10:28:24Z

Lösung über Session und Cookie

← Nächstältere Version		Version vom 15. Februar 2021, 10:28 Uhr
Zeile 231:		Zeile 231:
	Nach der Authentifizierung sendet der Server mittels des Response Headers '''Set-Cookie''' ein '''Cookie''' mit und erstellt somit eine '''Session (Sitzung)'''. Das '''Cookie''' wird auf Serverseite verschlüsselt und kann '''nicht''' durch den Client entschlüsselt und die Daten im Klartext gelesen werden. Es enthält einen '''Session Identifier''' welcher eine Zuordnung zur '''Session''' am Server dient. Die '''Session''' am Server kann alle möglichen Informationen enthalten, die der Identifikation des Benutzers dient (z.B.: ID). Der Client (z.B.: Browser) verwendet nun dieses '''Cookie''' bei jedem Request und sendet es im Header '''Cookie''' mit. Um die Zuordnung zu gewährleisten muss der Server die '''Session''' selbst speichern, dies kann aber beispielsweise auch über eine Datenbankanbindung realisiert werden, somit haben mehrere Anwendungsserver die Möglichkeit eine '''Session''' zuzuordnen und zu verifizieren.<br>		Nach der Authentifizierung sendet der Server mittels des Response Headers '''Set-Cookie''' ein '''Cookie''' mit und erstellt somit eine '''Session (Sitzung)'''. Das '''Cookie''' wird auf Serverseite verschlüsselt und kann '''nicht''' durch den Client entschlüsselt und die Daten im Klartext gelesen werden. Es enthält einen '''Session Identifier''' welcher eine Zuordnung zur '''Session''' am Server dient. Die '''Session''' am Server kann alle möglichen Informationen enthalten, die der Identifikation des Benutzers dient (z.B.: ID). Der Client (z.B.: Browser) verwendet nun dieses '''Cookie''' bei jedem Request und sendet es im Header '''Cookie''' mit. Um die Zuordnung zu gewährleisten muss der Server die '''Session''' selbst speichern, dies kann aber beispielsweise auch über eine Datenbankanbindung realisiert werden, somit haben mehrere Anwendungsserver die Möglichkeit eine '''Session''' zuzuordnen und zu verifizieren.<br>
	Weiters hat eine '''Session''' eine gewisse Gültigkeitsdauer. Wird die '''Session''' über eine längere Zeit nicht verwendet, so verliert diese ihre Gültigkeit.<br>		Weiters hat eine '''Session''' eine gewisse Gültigkeitsdauer. Wird die '''Session''' über eine längere Zeit nicht verwendet, so verliert diese ihre Gültigkeit.<br>
	Somit handelt es sich ~~hier~~ um eine '''stateful Authentication''' da Daten auf dem Server gespeichert werden müssen.		Somit handelt es sich hierbei um eine '''stateful Authentication''' da Daten auf dem Server gespeichert werden müssen.

	===== Token basierte Authentifizierung =====		===== Token basierte Authentifizierung =====

Drlue: /* Mögliche komplett zustandslose Lösungen */

2021-02-15T08:43:58Z

Mögliche komplett zustandslose Lösungen

← Nächstältere Version		Version vom 15. Februar 2021, 08:43 Uhr
Zeile 158:		Zeile 158:
	Ein Problem bei der Anforderung der '''Zustandslosigkeit''', stellt die '''Authentifizierung''' dar. Somit müsste der Client bei jeder Anfrage an den Webservice die kompletten Anmeldeinformationen mitsenden.		Ein Problem bei der Anforderung der '''Zustandslosigkeit''', stellt die '''Authentifizierung''' dar. Somit müsste der Client bei jeder Anfrage an den Webservice die kompletten Anmeldeinformationen mitsenden.
	===== Mögliche komplett zustandslose Lösungen =====		===== Mögliche komplett zustandslose Lösungen =====
	Eine mögliche Variante für eine komplett zustandslose Authentifizierung bietet '''Basic Auth'''. Im '''{{AL\|HTTP}} Header Authorization''' wird der Benutzername und das Passwort mitgesendet. Der Benutzername und das Passwort werden mit einem ~~'''~~:~~'''~~ getrennt und '''Base64''' codiert. ([https://www.base64encode.org/ Base64 encodieren], [https://www.base64decode.org/ Base 64 Decodieren])<br>		Eine mögliche Variante für eine komplett zustandslose Authentifizierung bietet '''Basic Auth'''. Im '''{{AL\|HTTP}} Header Authorization''' wird der Benutzername und das Passwort mitgesendet. Der Benutzername und das Passwort werden mit einem {{JSL\|:}} getrennt und '''Base64''' codiert. ([https://www.base64encode.org/ Base64 encodieren], [https://www.base64decode.org/ Base 64 Decodieren])<br>
	'''Benutzername:''' Luke<br>		'''Benutzername:''' Luke<br>
	'''Passwort:''' Luki<br>		'''Passwort:''' Luki<br>
Zeile 169:		Zeile 169:
	}}		}}
	Hierbei handelt es sich nun um eine '''zustandslose Authentifizierung''', da die komplette Anmeldeinformation bei jedem '''Request''' mitgesendet wird. Dadurch muss der Server natürlich auch bei jedem '''Request''' eine Überprüfung der Zugangsdaten vornehmen.<br>		Hierbei handelt es sich nun um eine '''zustandslose Authentifizierung''', da die komplette Anmeldeinformation bei jedem '''Request''' mitgesendet wird. Dadurch muss der Server natürlich auch bei jedem '''Request''' eine Überprüfung der Zugangsdaten vornehmen.<br>
	Die '''Basic Authentifizierung''' wird normalerweise nicht bei einem initialen Request an den Server gesendet. Jedoch kann sich der Client die Authentifizierungsmethode merken, und bei späteren Requests immer die '''Basic Authentifizierung''' mitsenden. Der Standardablauf verhält sich in etwa wie folgt. :		Die '''Basic Authentifizierung''' wird normalerweise nicht bei einem initialen Request an den Server gesendet. Jedoch kann sich der Client die Authentifizierungsmethode merken, und bei späteren Requests immer die '''Basic Authentifizierung''' mitsenden. Der Standardablauf verhält sich in etwa wie folgt:

	{\| class="wikitable"		{\| class="wikitable"

Drlue: /* Probleme bei der Zustandslosigkeit */

2021-02-15T08:43:24Z

Probleme bei der Zustandslosigkeit

← Nächstältere Version		Version vom 15. Februar 2021, 08:43 Uhr
Zeile 158:		Zeile 158:
	Ein Problem bei der Anforderung der '''Zustandslosigkeit''', stellt die '''Authentifizierung''' dar. Somit müsste der Client bei jeder Anfrage an den Webservice die kompletten Anmeldeinformationen mitsenden.		Ein Problem bei der Anforderung der '''Zustandslosigkeit''', stellt die '''Authentifizierung''' dar. Somit müsste der Client bei jeder Anfrage an den Webservice die kompletten Anmeldeinformationen mitsenden.
	===== Mögliche komplett zustandslose Lösungen =====		===== Mögliche komplett zustandslose Lösungen =====
	Eine mögliche Variante für eine komplett zustandslose Authentifizierung bietet '''Basic Auth'''. Im '''{{AL\|HTTP}} Header Authorization''' wird der Benutzername und das Passwort mitgesendet. Der Benutzername und das Passwort werden mit einem ''':''' getrennt und '''Base64''' ([https://www.base64encode.org/ ~~Encodieren~~], [https://www.base64decode.org/ Decodieren]) ~~codiert.~~<br>		Eine mögliche Variante für eine komplett zustandslose Authentifizierung bietet '''Basic Auth'''. Im '''{{AL\|HTTP}} Header Authorization''' wird der Benutzername und das Passwort mitgesendet. Der Benutzername und das Passwort werden mit einem ''':''' getrennt und '''Base64''' codiert. ([https://www.base64encode.org/ Base64 encodieren], [https://www.base64decode.org/ Base 64 Decodieren])<br>
	'''Benutzername:''' Luke<br>		'''Benutzername:''' Luke<br>
	'''Passwort:''' Luki<br>		'''Passwort:''' Luki<br>

Drlue: /* Probleme bei der Zustandslosigkeit */

2021-02-15T08:42:31Z

Probleme bei der Zustandslosigkeit

← Nächstältere Version		Version vom 15. Februar 2021, 08:42 Uhr
Zeile 156:		Zeile 156:

	==== Probleme bei der Zustandslosigkeit ====		==== Probleme bei der Zustandslosigkeit ====
	Ein Problem bei der Anforderung der Zustandslosigkeit, stellt die Authentifizierung dar. Somit müsste der Client bei jeder Anfrage an den Webservice die kompletten Anmeldeinformationen mitsenden.		Ein Problem bei der Anforderung der '''Zustandslosigkeit''', stellt die '''Authentifizierung''' dar. Somit müsste der Client bei jeder Anfrage an den Webservice die kompletten Anmeldeinformationen mitsenden.
	===== Mögliche komplett zustandslose Lösungen =====		===== Mögliche komplett zustandslose Lösungen =====
	Eine mögliche Variante für eine komplett zustandslose Authentifizierung bietet '''Basic Auth'''. Im '''{{AL\|HTTP}} Header Authorization''' wird der Benutzername und das Passwort mitgesendet. Der Benutzername und das Passwort werden mit einem ''':''' getrennt und '''Base64''' ([https://www.base64encode.org/ Encodieren], [https://www.base64decode.org/ Decodieren]) codiert.<br>		Eine mögliche Variante für eine komplett zustandslose Authentifizierung bietet '''Basic Auth'''. Im '''{{AL\|HTTP}} Header Authorization''' wird der Benutzername und das Passwort mitgesendet. Der Benutzername und das Passwort werden mit einem ''':''' getrennt und '''Base64''' ([https://www.base64encode.org/ Encodieren], [https://www.base64decode.org/ Decodieren]) codiert.<br>
Zeile 168:		Zeile 168:
	Authorization: Basic THVrZTpMdWtp		Authorization: Basic THVrZTpMdWtp
	}}		}}
	Hierbei handelt es sich nun um eine zustandslose Authentifizierung, da die komplette Anmeldeinformation bei jedem '''Request''' mitgesendet wird. Dadurch muss der Server natürlich auch bei jedem '''Request''' eine Überprüfung der Zugangsdaten vornehmen.<br>		Hierbei handelt es sich nun um eine '''zustandslose Authentifizierung''', da die komplette Anmeldeinformation bei jedem '''Request''' mitgesendet wird. Dadurch muss der Server natürlich auch bei jedem '''Request''' eine Überprüfung der Zugangsdaten vornehmen.<br>
	Die '''Basic Authentifizierung''' wird normalerweise nicht bei einem initialen Request an den Server gesendet. Jedoch kann sich der Client die Authentifizierungsmethode merken, und bei späteren Requests immer die '''Basic Authentifizierung''' mitsenden. Der Standardablauf verhält sich in etwa wie folgt. :		Die '''Basic Authentifizierung''' wird normalerweise nicht bei einem initialen Request an den Server gesendet. Jedoch kann sich der Client die Authentifizierungsmethode merken, und bei späteren Requests immer die '''Basic Authentifizierung''' mitsenden. Der Standardablauf verhält sich in etwa wie folgt. :

Drlue: /* Einheitliche Schnittstelle */

2021-02-15T08:40:36Z

Einheitliche Schnittstelle

← Nächstältere Version		Version vom 15. Februar 2021, 08:40 Uhr
Zeile 35:		Zeile 35:
	\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden		\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden
	\|}		\|}
	'''!!!ATTENTION!!!'''<br>Eine wichtige Anmerkung: Um eine Ressource nur in Teilen zu verändern sollte die '''Methode PATCH''' verwendet werden. Die '''PUT Methode''' ist zum Ersetzen einer bestehenden Ressource, also komplett ersetzen. Da wir das aber immer über '''PUT''' gemacht haben, lassen wirs dabei, halb so wild.<br>'''!!!ATTENTION!!!'''		'''!!!ATTENTION!!!'''<br>'''Eine wichtige Anmerkung:''' Um eine Ressource nur in Teilen zu verändern sollte die '''Methode PATCH''' verwendet werden. Die '''PUT Methode''' ist zum Ersetzen einer bestehenden Ressource, also komplett ersetzen. Da wir das aber immer über '''PUT''' gemacht haben, lassen wirs dabei, halb so wild.<br>'''!!!ATTENTION!!!'''
	<br>		<br>
	Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.		Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.

Drlue: /* Einheitliche Schnittstelle */

2021-02-15T08:40:26Z

Einheitliche Schnittstelle

← Nächstältere Version		Version vom 15. Februar 2021, 08:40 Uhr
Zeile 35:		Zeile 35:
	\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden		\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden
	\|}		\|}
	'''!!!ATTENTION!!!''' Eine wichtige Anmerkung: Um eine Ressource nur in Teilen zu verändern sollte die '''Methode PATCH''' verwendet werden. Die '''PUT Methode''' ist zum Ersetzen einer bestehenden Ressource, also komplett ersetzen. Da wir das aber immer über '''PUT''' gemacht haben, lassen wirs dabei, halb so wild.'''!!!ATTENTION!!!'''		'''!!!ATTENTION!!!'''<br>Eine wichtige Anmerkung: Um eine Ressource nur in Teilen zu verändern sollte die '''Methode PATCH''' verwendet werden. Die '''PUT Methode''' ist zum Ersetzen einer bestehenden Ressource, also komplett ersetzen. Da wir das aber immer über '''PUT''' gemacht haben, lassen wirs dabei, halb so wild.<br>'''!!!ATTENTION!!!'''
	<br>		<br>
	Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.		Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.

Drlue: /* Einheitliche Schnittstelle */

2021-02-15T08:40:08Z

Einheitliche Schnittstelle

← Nächstältere Version		Version vom 15. Februar 2021, 08:40 Uhr
Zeile 35:		Zeile 35:
	\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden		\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden
	\|}		\|}
	Eine wichtige Anmerkung: Um eine Ressource nur in Teilen zu verändern sollte die '''Methode PATCH''' verwendet werden. Die '''PUT Methode''' ist zum Ersetzen einer bestehenden Ressource, also komplett ersetzen. Da wir das aber immer über '''PUT''' gemacht haben, lassen wirs dabei, halb so wild.		'''!!!ATTENTION!!!''' Eine wichtige Anmerkung: Um eine Ressource nur in Teilen zu verändern sollte die '''Methode PATCH''' verwendet werden. Die '''PUT Methode''' ist zum Ersetzen einer bestehenden Ressource, also komplett ersetzen. Da wir das aber immer über '''PUT''' gemacht haben, lassen wirs dabei, halb so wild.'''!!!ATTENTION!!!'''
	<br>		<br>
	Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.		Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.

Drlue: /* Einheitliche Schnittstelle */

2021-02-15T08:39:23Z

Einheitliche Schnittstelle

← Nächstältere Version		Version vom 15. Februar 2021, 08:39 Uhr
Zeile 35:		Zeile 35:
	\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden		\| POST \|\| https://webservice.drlue.at/customer \|\| Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden
	\|}		\|}
			Eine wichtige Anmerkung: Um eine Ressource nur in Teilen zu verändern sollte die '''Methode PATCH''' verwendet werden. Die '''PUT Methode''' ist zum Ersetzen einer bestehenden Ressource, also komplett ersetzen. Da wir das aber immer über '''PUT''' gemacht haben, lassen wirs dabei, halb so wild.
	<br>		<br>
	Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.		Weiters soll die Repräsentation der Ressourcen unabhängig von deren eigentlicher Repräsenation z.B.: auf der Datenbank sein. Der Webservice soll es ermöglichen, die Repräsenation auszuwählen. Eine Webseite fordert die Daten beispielsweise als {{AL\|HTML}}, ein Android Client als {{AL\|Json}} an. Das Angeforderte Format wird über den '''HTTP''' '''Accept''' Header mittels eines '''MIME-Type''' festgelegt.