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

[Tornhoof]

GET mit Body ist nicht vorgesehen im Standard.

Jo, delete mit Body auch nicht

Die haben halt als Fall-back noch implementiert

Ich glaube du hast die Reihenfolge falsch rum, die originale search API von ES 2.0 war GET mit Body. Die Post Variante kam erst später. Die query Parameter Variante auch.
https://www.elastic.co/guide/en/elasticsearch/reference/1.3/search.html

Afaik erst mit der kommerziellem Verbreitung ab 5.0 wurden die anderen Apis eingeführt.

 

[Enomine88]

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.

[...]

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.

HTTP umfasst 1,5 Seiten. Elasticsearch / Elastic Stack umfasst bisher 10,5 Seiten. Query DSL kommt noch dazu.
Reicht das als Fokus auf ES? =)

Eine Masterarbeit ist für mich in meinem Verständnis auch eine Niederschrift von dem, was ich dazu gelernt habe. Da in meinem Studium HTTP mit seinen Methoden kein Bestandteil war, ist das für mich erstmal eine neue Info gewesen, die mMn daher berechtigt ist !kurz! aufgeschrieben zu werden.

So jetzt gebe ich mich mal weiter ans Tippeln =)

Danke - Enomine

 

[Enomine88]

Manchmal sieht man den Wald vor lauter Bäumen nicht.

Zumindest die REST = RESTful - Frage ist nun eindeutig geklärt. Vielleicht finde ich demnächst ja noch eine Antwort auf die P = NP - Frage.

Danke - Enomine

 

[Dalek]

Die ursrprüngliche Definition von REST findest du in der Dissertation von Roy Fielding:

https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Das ist die Originalquelle, und wenn du dich wirklich mit den Definitionen hier auseinandersetzen willst solltest du das zumindest mal kurz ansehen. Diese Definition von REST ist aber nicht das was in der Praxis als REST bezeichnet wird. In der Praxis wird praktisch alles was eine Web API die JSON liefert auch häufig als REST bezeichnet egal ob es die formalen Definitionen erfüllt.

Interessante Aspekte die man diskutieren kann sind sicher die Statelessness und die Konsequenzen davon. Die Idee das sich die API um Ressourcen dreht, im Gegensatz zu Ansätzen die eher in Richtung RPC gehen.

Edit: Hab zuerst übersehen das die Dissertation schon bekannt ist, aber löschen kann ich den Beitrag jetzt auch nicht mehr, ist im wesentlichen redundant mit bisherigen Diskussionen.

 

[lokked]

[..]
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
?
[..]

Welche Fragen sind denn noch offen? Oder wofür hättest du noch gerne Beispiele.

2.
a)
Die meisten gehen wohl davon aus, das du weißt wie du eine Funktion aus einer Library von konventionellem Code her aus aufrufst. Jeglicher Code bzw Funktionen die du nicht aus deinem eigenen Programm sondern von Bibliotheken aus aufrufst, ist somit API-Code. Die Schnittstelle sind dann die Funktionssignaturen und Datenstrukturen, die von der Library öffentlich gemacht bzw exportiert werden.

c + d)
Du hast es sicherlich gemerkt, RESTful ist in der Praxis einfach nur ein Euphemismus für die praktische Umsetzung der REST-Prinzipien. Also eine Verballhornung eines Akronyms, deshalb auch "pun". Adjektivierung mit Suffixen (-ish, -al, -ful) geht normal nur mit Nomen.

RESTful => Nicht ganz REST, aber größtenteils. Wir behalten uns jederzeit vor, das wegzulassen, was uns nicht in den Kram passt oder zu aufwenig umzusetzen wäre, keinen zusätzlichen Nutzen bringt, oder weil es für uns bequemer ist. Man könnte es aber einfach auch so definieren, das man gar nicht für sich beansprucht 100% konform zu sein und damit unproduktiven akademischem Diskussionen direkt aus dem Weg geht.

Nicht REST: Indirekte Datenlöschung oder -änderung per POST (mit entsprechenden Parametern oder Schlüsselwerten)
REST: DELETE/PUT/PATCH Verben für entsprechende Operationen benutzen und Operationen dafür auf Endpunkten implementieren.

Überlegungen dazu:
https://blog.ndepend.com/rest-vs-restful/
https://martinfowler.com/articles/richardsonMaturityModel.html

Kann helfen, sich damit mal auseinandergesetzt zu haben, z.B. wenn die eigene Programmierarbeit danach bewertet wird und das aus irgendeinem Grund relevant ist (z.B. bei Behörden) oder du selbst eine Evaluierung durchführen musst, z.B. das es als Qualitätskriterium für deinen oder fremden Code verwendet wird.

Meistens spielt es aber keine Rolle, da JSON Daten erst nachträglich (manuell) verifizierbar sind und dir jeder alles schicken kann, kannst du dir von einem konformeren API nichts kaufen, Vor allem nicht wenn es räudig umgesetzt worden ist und nur allgemeine Fehler ausgibt wie HTTP 500, "Internal Server Error".

Ich reihe mich da in die Riege derjenigen ein, die dir raten abzuklären ob du darauf wirklich herumreiten solltest, da jetzt hier auch keiner weiß was genau du mit Elasticsearch gemacht hast.
Also +1 auf "das wird vermutlich eh keiner lesen, und kann wenn dann sauber referenziert in den Anhang".

e) Prinzipiell jedes API das über HTTP zur Verfügung gestellt wird, also z.B.

• SOAP
• WebDAV
• JSON-RPC