Beispiele für APIs, WEB APIs, Webdienste, REST-Webdienste

[Enomine88]

Hallo,

ich tipsel an meiner Masterarbeit und habe mich schon intensiv in REST eingelesen. Kurz angerissen: REST ist ein Programmierparadigma für den Austausch von Daten zwischen verteilten Systemen, vor allem Webservices. REST hat 6 zentrale Eigenschaften/Voraussetzungen, damit ein System als REST-Webservice gelten kann. Webservice ist zu deutsch ein Webdienst und damit synonym.

Nun tauchen in der Literatur die Begriffe Webservice und Web-API sehr verworren auf. Manchmal bedeuten sie das selbe und werden synonym verwendet und manchmal versucht man die Begriffe voneinander abzugrenzen. Die Literatur ist sich weitgehend einig darüber, dass alle Webservices auch APIs sind, jedoch nicht jede API ein Webservice ist.
Ich habe mir mal eine Grafik gezeichnet wie ich meine wie die Inkludierungsbeziehungen zueinander sind:

Frage 1: Ist das so richtig dargestellt?
Frage 2: Was sind Beispiele für:

a) "offline-API"
b) WEB-API die nicht Webdienste sind
c) WEB-API REST-Webdienste
d) WEB-API REST-Ähnliche Webdienste (Siehe auch Richard Maturity Model)
e) WEB-API nicht-REST-Webdienste
?

Ich meine zu a) passt "Log4J", habt ihr weitere Beispiele?
Laut https://core.ac.uk/download/pdf/286438891.pdf (Evaluating the RESTfulness of “APIs from the Rough” von Arne Koschel, Irina Astrova) Seite 286 bieten PayPal, Spotify, Instagram und Github echte REST-Webdienste vom Typ c), wohingegen Twitter, Google Maps, Youtube, Wunderlist, LikedIn und OneDrive nur Rest-Ähnlich sind.
Leider sind das für den Leser kaum verständliche Beispiele, da sie nicht greifbar sind. Gibt es da vielleicht bessere Beispiele?

Danke - Enomine

 

[Sobber]

Sieht für mich komplett wirr aus und ich hätte da andere Definitionen.

Ich erwarte aber von jede wissenschaftliche Abhandlung, dass erstmal Begriffe selber noch definiert bevor sie die verwendet. Insbesondere in Bereichen wo gerne mal viele Leute unterschiedliche definitionen haben. Entsprechend würde ich auch erwarten das jede ernstzunehmende Literatur Quelle im ersten Kapitel erstmal Definitionen gibt, die dann auch für den jeweiligen Rest der Abhandlung gilt.
Diese können dann zwischen verschiedenen Quellen unterschiedlich sein. Insbesondere wenn die Authoren aus unterschiedlichen Gesellschaften/Regionen/Zeiten stammen.

Es hilft dir entsprechend nicht, wenn ich dir jetzt eine Definition geben würde, in deiner Literatur die Begriffe aber anders verwendet werden.

 

[TomH22]

API steht erst mal nur ganz allgemein für „Application Programming Interface“, und meint eine definierte Schnittstelle um auf eine Softwarekomponente zuzugreifen.Technisch gibt es dafür ganz verschiedene Methoden, es muss dabei auch weder um System- oder Prozessgrenzen gehen. Wenn die API z.B. lokal innerhalb eines Prozesses verwendet wird, geschieht das z.B. bei direkten lokalen Funktionsaufruf. Das ist z.B. bei der Windows API, mit der jedes Windows Programm mit dem Betriebsystem kommuniziert, der Fall. Vermutlich meinst Du das mit „offline API“ - das ist allerdings kein gebräuchlicher Begriff.

Verteilte Systeme kommunizieren heute in der Tat oft über Webservice Schnittstellen, d.h. die Übertragung findet auf Basis von HTTP/S Requests/Responses statt. Dabei ist REST aber auch nur eine Methode, eine anderes bekanntes Protokoll ist SOAP. In den letzten Jahren hat REST - oder eben an REST “angelehnte“ Methoden SOAP stark verdrängt.

Jetzt werden die meisten APIs eben nicht von Wissenschaftlern nach Lehrbuch entwickelt, sondern entstehen in der Praxis und die meisten Entwickler haben nicht vorher irgendeine Abhandlung über z.B. REST gelesen. Ein wichtiger Unterschied zwischen z.B. REST und SOAP ist, das letzteres ein sehr genau definiertes Protokoll ist, und die Schnittstellen eigentlich immer mit automatischen Tools generiert werden. REST Schnittstellen erlauben sehr viel mehr Freiheiten.

Echte REST Schnittstellen zeichnen sich vor allem durch Zustandslosigkeit aus, d.h. das jeder Aufruf für sich steht, unabhängig von vorhergehenden Aufrufen ist, bzw. wenn es Zustand gibt, dieser komplett im Client (z.B. in Form von Cookies) vorgehalten wird. Ein Beispiel dafür sind z.B. Authentication Tokens, die dem Server anzeigen, das der Benutzer sich authentifiziert hat.
“Zustandslosigkeit“ bezieht sich dabei aber nur auf den Zustand der API, der Dienst selber kann (und muss) in der Regel einen Zustand haben. Wenn z.B. über Paypal eine Zahlungstransaktion abgewickelt wird, muss der Vorgang ja gespeichert werden, sonst wäre das ganze ziemlich sinnlos.

In der Praxis wird meist alles als „REST“ bezeichnet, was den Methodenaufruf in einem URL kodiert, und JSON als Antwort zurückgibt, daher sind reale Systeme oft nur mehr oder weniger REST-Like.


Aber worum geht es denn in einer Deiner Masterarbeit?
Wenn ich ehrlich bin, erscheinenen mir Deine obigen Begriffsklärungen, auch mit so Phanatsiebegriffen wie “Offline-API“ noch weit von meinen Erwartungen an eine Masterarbeit entfernt. Zumindest wenn es eine Informatik Arbeit sein soll…

Was ist denn das Thema Deiner Arbeit? Ist REST zentraler Bestandteil der Arbeit, oder ist es nur ein Nebenthema?

 

[madmax2010]

Was ist der genaue Zweck dieser Beispiele im Kontext deines Themas?
Worüber schreibst du?
Wie willst du Informationen die du hier bekommst sauber zitieren? Du brauchst bestenfalls die Ursprungsquelle.

Nun tauchen in der Literatur die Begriffe Webservice und Web-API sehr verworren auf. Manchmal bedeuten sie das selbe und werden synonym verwendet und manchmal versucht man die Begriffe voneinander abzugrenzen

Hiern kannst du davon ausgehen, dass immer das gemeint ist, was im Kontext zu verstehen ist.
Und, denk doch mal darüber nach. Was ist eine Web API? eine API, die übers Web bereitgestellt. Kann man das als Dienst / Service bezeichnen? Ich fände das logisch.
Ein Webservice ist eine Dienstleistung im Web. Kann sie eine API bereitstellen? Ja. Muss sie das? Nein.

. Die Literatur ist sich weitgehend einig darüber, dass alle Webservices auch APIs sind, jedoch nicht jede API ein Webservice ist.

Irgendwie logisch..
Wobei nicht jeder webdienst eine API bereitstellt. Aber es gibt ja Selenium.

Wenn du die Grafik einbauen willst:
Versuch mal die mit draw.io sauber zu zeichnen. Das ist ja schon alles recht freestyle.

 

[Enomine88]

Aber worum geht es denn in einer Deiner Masterarbeit?
Wenn ich ehrlich bin, erscheinenen mir Deine obigen Begriffsklärungen, auch mit so Phanatsiebegriffen wie “Offline-API“ noch weit von meinen Erwartungen an eine Masterarbeit entfernt. Zumindest wenn es eine Informatik Arbeit sein soll…

Was ist denn das Thema Deiner Arbeit? Ist REST zentraler Bestandteil der Arbeit, oder ist es nur ein Nebenthema?

Hallo TomH22,
danke für deine ausführliche Antwort, mit der du bestätigst, was ich auch schon oft zu dem Thema gelesen habe.
Meine Masterarbeit handelt über Elasticsearch. Nachdem ich die Aufgabenstellung erklärt habe, erkläre ich was HTTP ist, nun wollte ich danach REST erklären und habe dann gemerkt, dass ich wohl zwischen HTTP und REST vielleicht noch über Webservices schreiben sollte. Nach REST kömmt dann ein ausführliches Kapitel über Elasticsearch (Entstehung, Technik usw.) danach wie man es benutzt (Querys) und danach kommt der praktische Teil, in welchem ich erkläre, was ich nun programmiert habe.

Danke - Enomine

Ergänzung (14. Oktober 2022)

Was ist der genaue Zweck dieser Beispiele im Kontext deines Themas?
Worüber schreibst du?
Wie willst du Informationen die du hier bekommst sauber zitieren? Du brauchst bestenfalls die Ursprungsquelle.

Hallo madmax2010,
danke auch dir für deinen Post.
Ich hoffe obige Informationen reichen, um deine ersten zwei Fragen zu beantworten. Zur dritten Frage:
Das hatte ich nicht vor von hier zu zitieren. Es ging mir vielmehr darum abzuchecken, ob ich mir jetzt ein richtiges Bild oder ein falsches Bild gemacht habe und ob es Leute gibt, die anderer Meinung sind. Vielleicht auch ein Input von jemand neutralem, der vielleicht zu dem Ergebnis kommt, dass ich das gar nicht so groß aufbauschen muss und einfach nur die Worte (Webservice, Web-API) verwende (im Kapitel REST) ohne sie zu erklären.

Wenn du die Grafik einbauen willst:
Versuch mal die mit draw.io sauber zu zeichnen. Das ist ja schon alles recht freestyle.

Ja das war bewusst ein Mockup. Draw.io kenne ich und benutze ich =)

Danke - Enomine

 

[mojitomay]

Wäre https://wttr.in/berlin eine"nicht-Rest-API"?

Denn bei wttr bekomme ich plain text zurück, kein json.

 

[Enomine88]

Ich erwarte aber von jede wissenschaftliche Abhandlung, dass erstmal Begriffe selber noch definiert bevor sie die verwendet.

Hallo Sobber,
danke für deine Nachricht.
Nach Definitionen habe ich nicht gefragt, ich fragte nach Beispielen
Als Definitionen wollte ich die (nach langer Suche) von mir gefundenen Definitionen von ISO und W3C benutzen:

https://www.iso.org/obp/ui/#iso:std:iso:ts:23029:ed-1:v1:en

application programming interface
API
set of well-defined methods, functions, protocols, routines or commands which application software uses with facilities of programming languages to invoke services

https://www.iso.org/obp/ui/#iso:std:iso:19168:-1:ed-1:v1:en

Web API
API using an architectural style that is founded on the technologies of the Web

https://www.w3.org/TR/ws-arch/

A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.

Leider sind die Definitionen auch ziemlich wenig aussagend, weil sie wenig erklären. Deswegen weiß ich nocht nicht genau, ob ich die nehmen soll oder lieber einen Erklärungstext schreiben soll, oder einfach die Definition der Begriffe Webservice und Web-API ganz weg lasse.

Danke - Enomine

Ergänzung (14. Oktober 2022)

Wäre https://wttr.in/berlin eine"nicht-Rest-API"?

Denn bei wttr bekomme ich plain text zurück, kein json.

Danke mojitomay,
sehr geiles Beispiel, was meinen die anderen zu seiner Frage?

Danke - Enomine

Ergänzung (14. Oktober 2022)

Wäre https://wttr.in/berlin eine"nicht-Rest-API"?

Denn bei wttr bekomme ich plain text zurück, kein json.

In seiner Dissertation
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
kommt das Wort "JSON" nicht vor.
Auch in seinem ergänzenden Kommentar von 2008 nicht:
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Von daher gehe ich nicht davon aus, dass JSON irgendwie Voraussetzung für REST ist.
Deswegen ist das JSON-Kapitel bei mir bisher nach REST und vor Elasticsearch eingeplant, weil JSON von Elasticsearch benutzt wird.
Von daher wäre "kein JSON zurück bekommen" für mich also kein Grund von einer "nicht-REST-API" auszugehen. Vielmehr handelt es sich ja um REST, wenn die 6 Voraussetzungen

• Client-Server
• Stateless
• Cache
• Uniform Interface
• Layered System
• Code-On-Demand

erfüllt sind. Dies ist für mich aber schwer zu kontrollieren, da ich nicht so Tief in der REST-Materie drin bin, als das ich das kontrollieren könnte (ich schreibe ja über ein anderes Thema).

Danke - Enomine

Ergänzung (14. Oktober 2022)

PS: Ein auch oft geschriebener Irrtum ist, dass REST HTTP erfordern würde. Das ist aber auch falsch. Er schreibt auf Seite 100 explizit "REST does not restrict communication to a particular protocol" und HTTP ist quasi nur eine Erwähnung. Dass HTTP heute meist benutzt wird liegt einfach an der Verbreitung von HTTP =)

Danke - Enomine

Ergänzung (14. Oktober 2022)

Ich merke gerade, dass die Originalquelle (also die Dissertation) kein einziges Mal die Begriffe "Web-API", "Web API" oder "Webservice" enthalten. Offensichtlich habe ich diese Begriffe nur aus der Sekundärliteratur, also aus Artikel aus dem Internet, die REST erklären. Wenn aber die Originalquelle ohne diese Begriffe auskommt, dann müsste ich doch eigentlich REST erklären können ohne diese Begriffe zu benutzen, oder?

Web API kommt z.B. auf Seite 138 als "Network-based API" vor.

Danke - Enomine

 

[andy_0]

Es wurde doch schon gesagt. Key ist API. Du musst erklären, was eine API ist. Und HTTP. Deine Literatur sieht das etwas anders, was formal sicherlich richtig ist, ist in der Realität aber nicht relevant.

Die Begriffe Webservice, WebAPI, Webdienst etc..pp. sind rein willkürlich. Die sagen: ne API (!) Via HTTP. Über das "Web". Was Web bedeutet ist da super frei. Wir betreiben klassische "WebAPIs" "offline" d.h. nur firmenintern zwischen Diensten aber eben ohne "Web". Nennen die Komponenten dennoch WebAPIs, einfach weil man REST-artige Endpoints häufig so nennt.

 

[Tornhoof]

Oh Gott, versuche nicht Rest zu erklären, dass was Roy Fielding in seiner Dissertation erklärt hat, hat nichts mit der Realität heutzutage zu tun. Häufig wird's daher nur RESTful oder einfach HTTP API genannt. Der zweite Ausdruck ist mittlerweile geläufiger.
Gerade Elastisc hat bei der ES API sich nicht wirklich um die REST Paradigmen gekümmert. Ich würde beides nicht in einem Satz verwenden.

Das ist ein großer Big Ball of mud

 

[Enomine88]

Hallo Tornhoof,

ich habe mich auch tagelang mit dem Begriff "RESTful" beschäftigt und habe eine Meinung zu dessen Bedeutung.
Ohne dich zu spoilern oder zu beeinflussen: Was meinst du bedeutet RESTful?

Danke - Enomine

Ergänzung (14. Oktober 2022)

Du musst erklären, was eine API ist. Und HTTP.

Die Begriffe Webservice, WebAPI, Webdienst etc..pp. sind rein willkürlich. Die sagen: ne API (!) Via HTTP.

Hallo andy_0,
interessanter Einwurf und ja da gebe ich dir Recht. Da sich die Literatur einige darüber ist, dass jeder Webservice eine API ist, könnte es ggf. ausreichen nur API zu erklären.

Danke - Enomine

 

[Tornhoof]

Ohne dich zu spoilern oder zu beeinflussen: Was meinst du bedeutet RESTful?

Cherry Picking von Konzepten aus REST auf einer HTTP API.
Also z.b. Identification und Manipulation of Resources, die meisten sehen das als nützlich an

Häufig ist es auch REST ohne HATEOAS (Hypermedia as the Engine of Application State) und abgeschwächtes Self Description.

Im Feld kannst du die APIs mit vollen HATEOAS wahrscheinlich an einer Hand abzählen (überspitzt formuliert), HATEOAS ist praktisch nicht umzusetzen in komplexeren APIs.

Man kanns auch so ausdrücken:

• Manager: Wir brauchen eine REST API
• Entwickler: Wir haben eine HTTP API
• Manager: Wir brauchen eine REST API, unsere Kunden wollen das
• Entwickler. Ok, wir nennen es RESTful API.

 

[netzgestaltung]

Als Altnernativbeispiel gibts noch die WordPress XML-RPC Schnittstelle (als nicht-rest).

Wobei es auch eine Rest-API, da haben die auch einen Kurzabschnitt "was ist eine Rest-API": https://developer.wordpress.org/rest-api/#what-is-a-rest-api

 

[Falc410]

danke für deine ausführliche Antwort, mit der du bestätigst, was ich auch schon oft zu dem Thema gelesen habe.
Meine Masterarbeit handelt über Elasticsearch. Nachdem ich die Aufgabenstellung erklärt habe, erkläre ich was HTTP ist, nun wollte ich danach REST erklären und habe dann gemerkt, dass ich wohl zwischen HTTP und REST vielleicht noch über Webservices schreiben sollte. Nach REST kömmt dann ein ausführliches Kapitel über Elasticsearch (Entstehung, Technik usw.) danach wie man es benutzt (Querys) und danach kommt der praktische Teil, in welchem ich erkläre, was ich nun programmiert habe.

Also nachdem ich selbst dutzende BA und MA betreut habe, mein Rat an dich: Sprich das Kapitel "Grundlagen" mal mit deinem Betreuer ab.
a) liest das sowieso niemand wirklich
b) musst du nur die Grundlagen erklären die für das weitere Verstädnis deiner Arbeit notwendig sind
c) darfst du natürlich ein entsprechendes Vorwissen deines Zielpublikums annehmen. Ein Informatikprofessor möchte nicht HTTP erklärt bekommen.

Ich hatte immer wieder Studenten die meinen in den Grundlagen alles erkären zu müssen. Das ist weder zielführend noch nötig. Der wichtige Teil deiner Arbeit sollte in den Kapitel danach kommen.

Wenn ich jetzt eine Problemstellung mit Elasticsearch löse in meiner MA, dann würde ich natürlich eine kurze Einführung in Elasticsearch geben und vor Allem erklären warum dieses Tool mich bei der Problemlösung am besten unterstützt hat (oder vielleicht waren es ja auch andere Constraints, Vorgaben etc.) aber wie gesagt, die Problemstellung und Lösung dessen sind der wichtige Teil deiner Arbeit.

Davon abgesehen ist es vollkommen normal in der Informatik, dass bestimmte Begriffe in der Literatur unterschiedlich definiert sind. Hier ist es auch vollkommen legitim, dies zu erwähnen und dann zu schreiben "für die restliche Arbeit beziehe ich mich auf die Definition nach XY".

 

[SheepShaver]

Hier werden viele Dinge durcheinander gewuerfelt. Also erstmal:
REST APIs sind HTTP APIs aber nicht umgekehrt. REST APIs in a nutshelll stellen CRUD Operationen zur Verfuegung. REST APIs muessen dem RESTful Paradigma entsprechen und hier vor allem dem Stateless-Grundsatz. Das hat NICHTS mit dem Server State zu tun, sondern mit dem Client State. Alle Requests muessen self-contained sein, d.h. der Client schickt immer saemtliche notwendigen Informationen im Request mit.
REST APIs werden zunehmend durch gRPC verdraengt. SOAP kann man heutzutage als archaisch bezeichnen, braucht man aber leider noch ab und zu, wenn man mit Bestandssoftware kommunizieren muss.

 

[andy_0]

Es gibt zunehmend andere Kommunikationsarten wie z.B. gRPC und SignalR, diese haben jedoch gänzlich andere Einsatzbereiche. Eine klassische "HTTP API" dient vor allem dazu einen Standard einzusetzen, den viele / alle Teilnehmer problemlos einsetzen können.

 

[Enomine88]

Cherry Picking von Konzepten aus REST auf einer HTTP API.
Also z.b. Identification und Manipulation of Resources, die meisten sehen das als nützlich an

Häufig ist es auch REST ohne HATEOAS (Hypermedia as the Engine of Application State) und abgeschwächtes Self Description.

Im Feld kannst du die APIs mit vollen HATEOAS wahrscheinlich an einer Hand abzählen (überspitzt formuliert), HATEOAS ist praktisch nicht umzusetzen in komplexeren APIs.

Man kanns auch so ausdrücken:

• Manager: Wir brauchen eine REST API
• Entwickler: Wir haben eine HTTP API
• Manager: Wir brauchen eine REST API, unsere Kunden wollen das
• Entwickler. Ok, wir nennen es RESTful API.

Okay, deine Übersetzung wäre also in die Richtung "RESTartige API". Also eine API mit REST-Elementen aber nicht allen.

Das ist Interessant. Denn ich ging bis vor kurzem noch davon aus, dass RESTful genau das Gegenteil bedeutet, nämlich, dass es die Eigenschaften / Elemente von REST besser / genauer / vollständiger als eine Vergleichsgruppe implementiert.
Mitlerweile denke ich das nicht mehr und habe folgenden Text entworfen:

Während der Recherche für die vorliegende Arbeit hatte ich sehr lange den Eindruck, dass RESTful eine Steigerungsform von REST sei. Also eine Beschreibung, dass die Vorgaben von REST besser oder vollständiger erfüllt seien als bei einer Vergleichsgruppe. Spät erkannte ich, dass es wahrscheinlicher ist, dass es sich bei dem Zusatz „-ful“ um eine Denominalisierung durch Derivation mithilfe der Adjektivierung handelt, wie es im Deutschen unter anderem mit den Suffixen „-lich“, „-voll“ oder „-reich“ angewandt wird. Alternativ könnte hier die dazu verwandte Bildung eines Adjektives aus einem Eigennamen vorliegen (https://www.duden.de/sprachwissen/sprachratgeber/Die-Bildung-von-Adjektiven-aus-Personennamen). Beispiele:

Nutzen	nützlich	Use	useful
Hilfe	hilfreich	Help	helpful
Kraft	kraftvoll	Power	powerful
Das Weltbild des Kopernikus​	kopernikanisches Weltbild​	The world view of Copernicus​	copernican world view​
Die Voraussetzungen des REST​	„RESTsche Voraussetzungen“​	The requirements of REST​	RESTful requirements​
Die API erfüllt die REST Bedingungen​	„RESTsche API“​	The API complies the REST conditions​	RESTful API​

Von einem englisch native speaker, der den Begriff bereits 2003 in einem Artikel (https://www.networkworld.com/article/2339954/a-restful-approach-to-web-services.html) benutze, habe ich danach gesagt bekommen:

Hi Michael.

It is a pun. To have a restful night’s sleep is to sleep well.

For something to be RESTful simply means it has the qualities of REST.

Bob

Ich weiß noch nicht so ganz wie ich das interpretieren soll. Jedenfalls bestätigt es meiner Meinung nach auch mehr meine theorie, dass REST und RESTful bedeutungsgleich sind. Dies wird auch dadurch unterstrichen, dass Roy Fielding 2008 diesen Artikel veröffentlichte:
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Dort schreibt er

In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.

. Und drückt damit aus, dass RESTful mindestens genau so viel bedeutet wie REST API.

Danke - Enomine

Ergänzung (14. Oktober 2022)

b) musst du nur die Grundlagen erklären die für das weitere Verstädnis deiner Arbeit notwendig sind

Genau und HTTP ist definitiv notwendig. REST ist tatsächlich weniger notwendig, um zu verstehen wie Elasticsearch Querys funktionieren, aber es wäre schon komisch das raus zu lassen. Webservice / (Web) API ist aber nicht nötig, um das weitere zu verstehen. Deswegen lass ich es vielleicht doch raus.

c) darfst du natürlich ein entsprechendes Vorwissen deines Zielpublikums annehmen. Ein Informatikprofessor möchte nicht HTTP erklärt bekommen.

Ich fand es schon wichtig, da bei den Elasticsearch-Querys ganz wichtig ist das konzept von GET, PUT, POST verstanden zu haben und in meinen Augen sonst eine wichtige Grundlage fehlen würde.

Wenn ich jetzt eine Problemstellung mit Elasticsearch löse in meiner MA, dann würde ich natürlich eine kurze Einführung in Elasticsearch geben und vor Allem erklären warum dieses Tool mich bei der Problemlösung am besten unterstützt hat (oder vielleicht waren es ja auch andere Constraints, Vorgaben etc.) aber wie gesagt, die Problemstellung und Lösung dessen sind der wichtige Teil deiner Arbeit.

Leider wird der praktische Teil relativ kurz ausfallen, da das Projekt beim Arbeitgeber relativ ins Wasser gefallen ist mangels regelmäßiger Betreuung.

Danke - Enomine

 

[andy_0]

GET, PUT, POST, DELETE, HEAD und PATCH sind die HTTP Request Methods. Das hat mit REST gar nichts zu tun.

Ich würde dir entsprechend empfehlen dich auf das Thema API und HTTP zu beschränken. Ob die Schnittstelle mit REST, Binary Packages etc. pp. funktioniert, ist im Detail für einen Nutzer vollkommen unerheblich. Schon die Erwähnung von HTTP NUR für die Request Methods würde ich lassen. Jedoch ist HTTP eben viel mehr, nämlich das gesamte Transportprotokoll und würde es entsprechend schon erwähnen.

 

[Enomine88]

GET, PUT, POST, DELETE, HEAD und PATCH sind die HTTP Request Methods. Das hat mit REST gar nichts zu tun.

Korrekt, das habe ich auch nie behauptet =) Siehe Seite 100 in Fieldings Dissertation.

Ich würde dir entsprechend empfehlen dich auf das Thema API und HTTP zu beschränken. Ob die Schnittstelle mit REST, Binary Packages etc. pp. funktioniert, ist im Detail für einen Nutzer vollkommen unerheblich. Schon die Erwähnung von HTTP NUR für die Request Methods würde ich lassen. Jedoch ist HTTP eben viel mehr, nämlich das gesamte Transportprotokoll und würde es entsprechend schon erwähnen.

Zu HTTP habe ich 1,5-2 Seiten geschrieben inklusive der Methoden.

Danke - Enomine

 

[Tornhoof]

Und drückt damit aus, dass RESTful mindestens genau so viel bedeutet wie REST API.

Du hast schon Recht, die Nomenklatur ist nicht eindeutig. Auch die Aussagen von Fielding kannst entsprechend interpretieren, zb wenn es nicht RESTful ist, kann es nicht REST sein.
Andere sagen einfach REST ist der Stil, RESTful ist die Umsetzung.


Viele sind auch mittlerweile einfach dazu übergegangen Apis im Sinne von Richardson's maturity Model zu beschreiben.
https://martinfowler.com/articles/richardsonMaturityModel.html

Fielding sagt explizit dass REST Level 3 beinhalten muss.
In der Realität gibt's wie gesagt selten Level 3.

Daher ist die einfache Aussage HTTP API

Ich fand es schon wichtig, da bei den Elasticsearch-Querys ganz wichtig ist das konzept von GET, PUT, POST

Genau das ist ein Big Ball of mud bei ES, da du sehr viele Operationen als GET ausführen kannst aber auch als POST. Das führt dann zu undefiniertem verhalten wie get mit Body oder delete mit Body.
https://www.elastic.co/guide/en/elasticsearch/reference/current/api-conventions.html#get-requests

Daher, vergiss Fieldings REST im Kontext von ES.

 

[Falc410]

Leider wird der praktische Teil relativ kurz ausfallen, da das Projekt beim Arbeitgeber relativ ins Wasser gefallen ist mangels regelmäßiger Betreuung.

Gerade dann ist es umso wichtiger, dass der konzeptuelle Teil deiner Arbeit gut und ausführlich ist. Wie gesagt, kein Mitarbeiter des Lehrstuhls möchte irgendwas über Grundlagen lesen. Und in einer Arbeit in der es hauptsächlich um Elasticsearch geht, würde ich auch nicht erwarten, dass ich 2 Seiten über HTTP GET oder DELETE lesen muss und warum ich bei manchen Queries einen POST absetzen muss und bei anderen nicht.
Du solltest wenn du schon praktisch so gut wie nichts umgesetzt hast, zumindest SEHR ausführlich beschreiben wie du das Problem hättest lösen wollen.

Gerade Arbeiten die bei einer externen Firma durchgeführt werden, können ganz schnell nach hinten losgehen. Ich weiß nicht ob du an einer FH oder einer Uni studierst, das macht auch noch einmal einen Unterschied. Aber ich habe schon einige Studenten gesehen die sehr schlechte Ergebnisse (bis hin zum nicht bestehen) bekommen haben, weil die Firma unzufrieden war und der Prof. mit denen halt eine Geschäftsbeziehung hatte. Oder andersrum, der Prof. möchte eine wissenschaftliche Arbeit, die Firma eine kostenlose Arbeitskraft die irgendwas implementiert.

Anstatt auf HTTP einzugehen, hätte ich lieber etwas darüber gelesen warum Elastic keine Datenbank sondern eine Search Engine ist, weil die meisten Leute die sich nicht damit auskennen, erst einmal denken: Ach das ist halt so eine NoSQL Datenbank. Aber gut, wir kennen dein genaues Thema ja nicht, trotzdem, Grundlagen Kapitel knapp halten und den Fokus auf den Hauptteil legen.

Ergänzung (14. Oktober 2022)

Genau das ist ein Big Ball of mud bei ES, da du sehr viele Operationen als GET ausführen kannst aber auch als POST. Das führt dann zu undefiniertem verhalten wie get mit Body oder delete mit Body.

GET mit Body ist nicht vorgesehen im Standard. Das hat aber erstmal nichts mit Elastic zu tun. Die haben halt als Fall-back noch implementiert, dass sie es trotzdem akzeptieren und zur Not die Parameter parsen.