Representational State Transfer (REST) - Revision history

Hoffmmqj at 22:34, 9 December 2019

2019-12-09T22:34:38Z

Haussknl: /* Domain Informationen */

2019-07-08T09:53:40Z

Domain Informationen

← Older revision		Revision as of 09:53, 8 July 2019
Line 60:		Line 60:

	In diesem REST-Request ist das Objekt unserer Anfrage (141.20.5.218) als Teil der URL kodiert. Gerade bei Anfragen mit mehrerern Parametern (v.A., wenn beispielsweise auch ein API-Key erforderlich ist) werden die Parameter häufig auch als GET-Parameter übermittelt, die mit einem `?` von dem Rest der URL und mit `&` voneinander getrennt sind.		In diesem REST-Request ist das Objekt unserer Anfrage (141.20.5.218) als Teil der URL kodiert. Gerade bei Anfragen mit mehrerern Parametern (v.A., wenn beispielsweise auch ein API-Key erforderlich ist) werden die Parameter häufig auch als GET-Parameter übermittelt, die mit einem `?` von dem Rest der URL und mit `&` voneinander getrennt sind.
			Nicht kodiert könnte die Anfrage folgendermaßen aussehen:

			<code>
			GET /json/141.20.5.218 HTTP/1.1
			Host: www.ip-api.com

			</code>

	Wird dieser Request (mit der IP-Adresse der Humboldt-Universität) gesendet, könnte die Antwort folgendermaßen aussehen:		Wird dieser Request (mit der IP-Adresse der Humboldt-Universität) gesendet, könnte die Antwort folgendermaßen aussehen:

Haussknl at 09:14, 8 July 2019

2019-07-08T09:14:21Z

@@ Line 31: / Line 31: @@
 ==Code on Demand:==
 Dieses optionale Constraint besagt, dass REST-Schnittstellen auch ermöglichen sollten, als Antwort auf API-Anfragen Code zurückzuliefern, der dann von der Client-Anwendung weiterverarbeitet werden kann. Anwendung findet dies beispielsweise bei dynamischen Java-Applets, die dann auf Webseiten eingebettet werden können.
 =Beispiel REST:=

Kochalsm: /* Wetter API */

2018-10-18T09:42:21Z

Wetter API

← Older revision		Revision as of 09:42, 18 October 2018
Line 50:		Line 50:
	==Wetter API==		==Wetter API==

	~~Für~~ aktuelle Wetterdaten, stellt zum Beispiel openweathermap.com eine umfangreiche RestfulAPI zur Verfügung.		ür aktuelle Wetterdaten, stellt zum Beispiel openweathermap.com eine umfangreiche RestfulAPI zur Verfügung. Genau wie im ersten Beispiel muss der Client an den Server eine GET-Anfrage mit den vereinbarten Parametern übersenden. In diesem Fall erhält die GET-Anfrage die URL sowie die Parameter Stadt, Ländercode und den API Key.

			https://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=b6907d289e10d714a6e88b30761fae22

			Mit dieser Anfrage werden die Wetterdaten von London abgefragt und ebenfalls als Teil der URL kodiert. Anders als im ersten Beispiel werden die Parameter mit einem '''q''' vom Rest der URL getrennt: Die Trennung der unterschiedlichen Parameter erfolgt wieder mit einem '''&'''.

			Als Antwort liefert der Server folgende Daten standardmäßig im JSON Format zurück:

			{"coord":{"lon":-0.13,"lat":51.51},"weather":[{"id":300,"main":"Drizzle","description":"light intensity drizzle","icon":"09d"}],"base":"stations","main":
			{"temp":280.32,"pressure":1012,"humidity":81,"temp_min":279.15,"temp_max":281.15},"visibility":10000,"wind":{"speed":4.1,"deg":80},"clouds":{"all":90},"dt":1485789600,"sys":
			{"type":1,"id":5091,"message":0.0103,"country":"GB","sunrise":1485762037,"sunset":1485794875},"id":2643743,"name":"London","cod":200}

	=Quellen=		=Quellen=

Kochalsm: /* Wetter API */

2018-07-24T06:00:05Z

Wetter API

← Older revision		Revision as of 06:00, 24 July 2018
Line 49:		Line 49:

	==Wetter API==		==Wetter API==

			Für aktuelle Wetterdaten, stellt zum Beispiel openweathermap.com eine umfangreiche RestfulAPI zur Verfügung.

	=Quellen=		=Quellen=

Kochalsm: /* Client-Server */

2018-07-24T05:57:24Z

Client-Server

← Older revision		Revision as of 05:57, 24 July 2018
Line 5:		Line 5:

	==Client-Server==		==Client-Server==
			Die einheitliche Schnittstelle trennt die Daten-Schicht von der Benutzer-Schnittstelle. Diese Trennung bedeutet, dass beispielsweise Clients sich nicht mit Datenspeicherung befassen, die intern auf dem Server verbleibt, so dass die Portabilität des Client-Codes verbessert wird. Server befassen sich nicht mit der Benutzerschnittstelle oder dem Benutzerstatus, sodass Server einfacher und besser skalierbar sind. Server und Clients können auch unabhängig ersetzt und entwickelt werden, solange die Schnittstelle nicht geändert wird.
	Es wird eine Client-Server-Architektur gefordert. Hierbei wird die Daten-Schicht von der Benutzer-Schnittstelle getrennt. Dieses ermöglicht eine einfachere Portierung der Schnittstelle über mehrer Platformen. Zudem wird die Skalierbarkeit erhöht durch die Vereinfachung der Server-Komponenten.

	==Stateless==		==Stateless==

Kochalsm: /* Rest-Constraints */

2018-07-19T16:25:50Z

Rest-Constraints

← Older revision		Revision as of 16:25, 19 July 2018
Line 4:		Line 4:
	=Rest-Constraints=		=Rest-Constraints=

	==~~Layered System:~~==		==Client-Server==
			Es wird eine Client-Server-Architektur gefordert. Hierbei wird die Daten-Schicht von der Benutzer-Schnittstelle getrennt. Dieses ermöglicht eine einfachere Portierung der Schnittstelle über mehrer Platformen. Zudem wird die Skalierbarkeit erhöht durch die Vereinfachung der Server-Komponenten.

			==Stateless==
			Die Kommunikation zwischen Client und Server hat Zustandslos zu erfolgen. Hierzu muss jede Anfrage eines Clients alle nötigen Informationen zur Beantwortung beinhalten und ohne Vorwissen über vorangegangene Anfragen vom Server ausgewertet und beantwortet werden können. Das bedeutet auch, dass der Client alle für die Kommunikation nötigen Zustände selbst verwaltet. Bei Wiederholung einer Anfrage wird somit immer die gleiche Antwort vom Server erwartet. Dieses erhöht die Skalierbarkeit, da Anfragen auf mehrere Server verteilt werden können ohne dass ein Server den Zustand des anderen Servers kennen muss. Bei verteilten Servern ist natürlich besondere Vorsicht geboten wenn zum Beispiel nach einer Änderungsoperationen lesend auf den inkonsistente Zustand zugegriffen wird.

			==Cache==
			Daten in einer Server-Antwort sollen explizit oder implizit als Cache-fähig oder -unfähig markiert werden. Die Verwendung eines Zwischenspeichers (Cache) auf Client-Seite steigert die Systemkapazität und die vom Benutzer empfundene Geschwindigkeit, da gleiche Anfragen mit Cache-fähigen Antworten nicht mehrfach an den oder die Server gestellt werden. Beim Cachen ist natürlich sehr genau abzuwägen welche Daten sich zum Cachen eignen. Es besteht die Gefahr sich ungewollte Effekte einzuhandeln, wie zum Beispiel durch die Verwendung veralteter Messwerte in einem sehr dynamischen Regelkreislauf. Cachen wird im Allgemeinen auch immer einen höheren Bedarf an Speicherplatz auf der Client-Seite erfordern.

			==Layered System==
	Für Clients soll nicht ersichtlich sein, ob diese direkt zum eigentlichen Server verbunden sind, oder nur zu einer Schnittstelle, die lediglich Zugriff auf die REST-API bietet. Dadurch kann ein Server mehrschichtig aufgebaut werden, wobei die unteren Schichten dem Clienten verborgen bleiben. Dies ermöglicht es weiterhin, die Struktur des Servers zu verändern, ohne dass bestehende REST-Anfragen angepasst werden müssen, solange die obere Schicht unverändert bleibt.		Für Clients soll nicht ersichtlich sein, ob diese direkt zum eigentlichen Server verbunden sind, oder nur zu einer Schnittstelle, die lediglich Zugriff auf die REST-API bietet. Dadurch kann ein Server mehrschichtig aufgebaut werden, wobei die unteren Schichten dem Clienten verborgen bleiben. Dies ermöglicht es weiterhin, die Struktur des Servers zu verändern, ohne dass bestehende REST-Anfragen angepasst werden müssen, solange die obere Schicht unverändert bleibt.

Kochalsm: /* Domain Informationen */

2018-06-29T08:59:50Z

Domain Informationen

← Older revision		Revision as of 08:59, 29 June 2018
Line 27:		Line 27:
	==Domain Informationen==		==Domain Informationen==

	Um Informationen über eine bestimmte IP-Adresse oder Domain zu ermitteln, bietet [http://ip-api.com ip-api.com]eine RESTful-API an. Dazu stellt der Client zunächst eine reguläre GET-Anfrage an den Server, die Implementierung dabei hängt von der Art und Programmiersprache der Client-Anwendung ab. In python beispielsweise bietet das Modul urllib eine einfache Bibliothek für Internetkommunikation. Alternativ ist es auch möglich, die Anfrage einfach in die Adresszeile eines regulären Internetbrowsers zu kopieren, und dann die unformatierte Antwort im Browserfenster zu begutachten.<ref>API Dokumentation http://ip-api.com/docs/#ip_geolocation_api Abgerufen am 06.Mai 2018 (englisch) </ref>		Um Informationen über eine bestimmte IP-Adresse oder Domain zu ermitteln, bietet [http://ip-api.com ip-api.com]eine RESTful-API an. Dazu stellt der Client zunächst eine reguläre GET-Anfrage an den Server, die Implementierung dabei hängt von der Art und Programmiersprache der Client-Anwendung ab. In python beispielsweise bietet das Modul urllib eine einfache Bibliothek für Internetkommunikation. Alternativ ist es auch möglich, die Anfrage einfach in die Adresszeile eines regulären Internetbrowsers zu kopieren, und dann die unformatierte Antwort im Browserfenster zu begutachten.<ref>API Dokumentation http://ip-api.com/docs/#ip_geolocation_api Abgerufen am 6.Mai 2018 (englisch) </ref>

	[http://ip-api.com/json/141.20.5.218 http://ip-api.com/json/141.20.5.218]		[http://ip-api.com/json/141.20.5.218 http://ip-api.com/json/141.20.5.218]

Kochalsm: /* Domain Informationen */

2018-06-29T08:59:25Z

Domain Informationen

← Older revision		Revision as of 08:59, 29 June 2018
Line 27:		Line 27:
	==Domain Informationen==		==Domain Informationen==

	Um Informationen über eine bestimmte IP-Adresse oder Domain zu ermitteln, bietet [http://ip-api.com ip-api.com]eine RESTful-API an. Dazu stellt der Client zunächst eine reguläre GET-Anfrage an den Server, die Implementierung dabei hängt von der Art und Programmiersprache der Client-Anwendung ab. In python beispielsweise bietet das Modul urllib eine einfache Bibliothek für Internetkommunikation. Alternativ ist es auch möglich, die Anfrage einfach in die Adresszeile eines regulären Internetbrowsers zu kopieren, und dann die unformatierte Antwort im Browserfenster zu begutachten.		Um Informationen über eine bestimmte IP-Adresse oder Domain zu ermitteln, bietet [http://ip-api.com ip-api.com]eine RESTful-API an. Dazu stellt der Client zunächst eine reguläre GET-Anfrage an den Server, die Implementierung dabei hängt von der Art und Programmiersprache der Client-Anwendung ab. In python beispielsweise bietet das Modul urllib eine einfache Bibliothek für Internetkommunikation. Alternativ ist es auch möglich, die Anfrage einfach in die Adresszeile eines regulären Internetbrowsers zu kopieren, und dann die unformatierte Antwort im Browserfenster zu begutachten.<ref>API Dokumentation http://ip-api.com/docs/#ip_geolocation_api Abgerufen am 06.Mai 2018 (englisch) </ref>

	[http://ip-api.com/json/141.20.5.218 http://ip-api.com/json/141.20.5.218]		[http://ip-api.com/json/141.20.5.218 http://ip-api.com/json/141.20.5.218]
Line 35:		Line 35:
	Wird dieser Request (mit der IP-Adresse der Humboldt-Universität) gesendet, könnte die Antwort folgendermaßen aussehen:		Wird dieser Request (mit der IP-Adresse der Humboldt-Universität) gesendet, könnte die Antwort folgendermaßen aussehen:

	`{"as":"AS680 Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.","city":"Berlin","country":"Germany","countryCode":"DE","isp":"Humboldt-Universitaet zu Berlin","lat":52.5167,"lon":13.4,"org":"Humboldt-Universitaet zu Berlin","query":"141.20.5.218","region":"BE","regionName":"Land Berlin","status":"success","timezone":"Europe/Berlin","zip":"12529"}`		<code>{"as":"AS680 Verein zur Foerderung eines Deutschen Forschungsnetzes e.V.","city":"Berlin","country":"Germany","countryCode":"DE","isp":"Humboldt-Universitaet zu Berlin","lat":52.5167,"lon":13.4,"org":"Humboldt-Universitaet zu Berlin","query":"141.20.5.218","region":"BE","regionName":"Land Berlin","status":"success","timezone":"Europe/Berlin","zip":"12529"}</code>

	Hierbei sind sämtliche Informationen im JSON-Format kodiert, was eine leichte Weiterverarbeitung der Ergebnisse ermöglicht.		Hierbei sind sämtliche Informationen im JSON-Format kodiert, was eine leichte Weiterverarbeitung der Ergebnisse ermöglicht.

Kochalsm: /* Hypermedia As The Engine Of Application State (HATEOAS): */

2018-06-29T08:53:15Z

Hypermedia As The Engine Of Application State (HATEOAS):

← Older revision		Revision as of 08:53, 29 June 2018
Line 17:		Line 17:
	Diese Eigenschaft greift das "statelessness"-Constraint auf und besagt, dass der Inhalt der Nachrichten so wie er ist ("as is"), also ohne weitere Informationen von außen, weiterverarbeitet werden sollen kann. Solche Nachrichten werden auch als kontextfrei bezeichnet.		Diese Eigenschaft greift das "statelessness"-Constraint auf und besagt, dass der Inhalt der Nachrichten so wie er ist ("as is"), also ohne weitere Informationen von außen, weiterverarbeitet werden sollen kann. Solche Nachrichten werden auch als kontextfrei bezeichnet.
	===Hypermedia As The Engine Of Application State (HATEOAS):===		===Hypermedia As The Engine Of Application State (HATEOAS):===

	Laut Roy Fielding, dem Autoren der ursprünglichen REST-Spezifikation, ist dies die wichtigste aller REST-Eigenschaften. Dennoch wird sie von vielen Entwicklern missachtet. Die Idee hinter HATEOAS ist, dass Repräsentationen von Ressourcen jeweils auch immer Links mitliefern, die die weitere Bearbeitung der Ressource ermöglichen. Wenn HATEOAS korrekt implementiert wird müssen die genauen URLS der Rest-Anfragen nicht mehr hart in der Client-Application kodiert sein, sondern können direkt aus der vorhergehenden Antwort übernommen werden.		Laut Roy Fielding, dem Autoren der ursprünglichen REST-Spezifikation, ist dies die wichtigste aller REST-Eigenschaften. Dennoch wird sie von vielen Entwicklern missachtet. Die Idee hinter HATEOAS ist, dass Repräsentationen von Ressourcen jeweils auch immer Links mitliefern, die die weitere Bearbeitung der Ressource ermöglichen. Wenn HATEOAS korrekt implementiert wird müssen die genauen URLS der Rest-Anfragen nicht mehr hart in der Client-Application kodiert sein, sondern können direkt aus der vorhergehenden Antwort übernommen werden.<ref>https://spring.io/understanding/HATEOAS Abgerufen am 6. Mai 2018 (englisch)</ref>


	==Code on Demand:==		==Code on Demand:==
	Dieses optionale Constraint besagt, dass REST-Schnittstellen auch ermöglichen sollten, als Antwort auf API-Anfragen Code zurückzuliefern, der dann von der Client-Anwendung weiterverarbeitet werden kann. Anwendung findet dies beispielsweise bei dynamischen Java-Applets, die dann auf Webseiten eingebettet werden können.		Dieses optionale Constraint besagt, dass REST-Schnittstellen auch ermöglichen sollten, als Antwort auf API-Anfragen Code zurückzuliefern, der dann von der Client-Anwendung weiterverarbeitet werden kann. Anwendung findet dies beispielsweise bei dynamischen Java-Applets, die dann auf Webseiten eingebettet werden können.