Wie soll eine HTTP-API aufgerufen werden, die nicht REST-konform ist? [geschlossen]

Wie würden Sie eine auf HTTP basierende API nennen, die URI zur Benennung von Ressourcen und HTTP-Verben (PUT, POST, DELETE, GET ...) zur Manipulation dieser Ressourcen verwendet?

Laut Roy Fieldings Beschwerden handelt es sich nicht um REST, da es kein Hypermedium gibt.

Intern nennt es in meinem Team jeder "REST-API". Ich nenne es "REST-like", aber es ist nicht beschreibend und seine Bedeutung ist unscharf. Ich bin ziemlich verwirrt darüber, da es große Meinungsverschiedenheiten über REST gibt. Ich möchte nicht an Flammenkriegen teilnehmen, sondern nur die richtigen Begriffe verwenden.

Nennen Sie es eine HTTP-API .

Es entspricht den HTTP-Standards und enthält keine weiteren Ebenen (z. B. SOAP).

Die HTTP-Standards definieren Ressourcen, Verben, Überschriften, Inhaltsverhandlungen usw.

REST (REpresentational State Transfer) ist eine Architektur mit Anforderungen, die für vorhandene HTTP-Standards geeignet sind, HTTP funktioniert jedoch alleine.

Nach meiner Erfahrung sollten sich 90% der "REST-HTTP-APIs" "nur" eine HTTP-API nennen.

Schämen Sie sich nicht, auf das REST-Label zu verzichten. Wie bei Microservices und nicht relationalen Datenbanken müssen Sie keine RESTful-API haben, um cool zu sein. Roy machte sich daran, die langlebigste, abwärtskompatibelste und vernetzteste Anwendungsarchitektur zu entwickeln, die er konnte. Er hat gute Arbeit geleistet. Aber nicht alles braucht mehr als 40 Jahre Kompatibilität.

Richardson Maturity Models geht so

0. POST überall. Ein einzelner Endpunkt. (SEIFE)
1. POST überall. Mehrere Endpunkte. (Ressourcen)
2. HTTP VERBS. Mehrere Endpunkte.
3. Wie 2 und gibt Links zu Ressourcen zurück. (RUHIG)

Entsprechend dem Modell würde ich es einen Webservice nennen, der mit Richardson Level 2 übereinstimmt, oder so ähnlich.

http://martinfowler.com/articles/richardsonMaturityModel.html

Hypermedia wurde mit REST-ähnlichen APIs nie wirklich populär - bis zu dem Punkt, dass der Begriff RESTful nicht ausreicht, um eine API von anderen "RESTful" -Web-APIs zu unterscheiden, wenn eine API tatsächlich Hypermedia-Navigation implementiert. REST ist zu einem Sammelbegriff geworden, oder es wurden ressourcenbasierte Web-APIs und neue Namen wie die Hypermedia-API entwickelt  , um sich auf das Hypermedia-Konzept zu konzentrieren.

Ich möchte nicht wirklich die Verwendung falscher Begriffe befürworten, aber ich denke, dass die allgemeine moderne Interpretation von REST für die meisten Menschen einfach die Verwendung einheitlicher URLs und HTTP-Verben bedeutet. Es ist nicht korrekt, aber jeder, der die Fieldings-Definition kennt, sollte auch wissen, dass viele andere dies nicht wissen. Andererseits weiß jeder, der REST nur durch Beobachtung der Implementierung vorhandener "RESTful" -APIs kennt, nicht, wovon Sie sprechen, wenn Sie weniger bekannte REST-Einschränkungen wie HATEOAS oder On-Demand-Code erwähnen. Fielding mag es vielleicht nicht, aber ich denke, es ist zu spät, zur ursprünglichen Definition zurückzukehren *. Und seien wir ehrlich: Wenn Sie jemanden zum ersten Mal über seine REST-API sprechen hören, gehen Sie sofort davon aus, dass sie keine Hypermedien enthält, nicht wahr?

Das Beharren auf der korrekten Definition von RESTful schafft normalerweise nur zusätzliche Verwirrung. Wie bei vielen Begriffen, die ihre Bedeutung im Laufe der Zeit geändert haben oder die die Massen einfach falsch übernommen haben, weiß ich zu schätzen, dass jemand die ursprüngliche Definition kennt, aber ich würde niemanden korrigieren, der die umfassendere moderne Interpretation von REST verwendet.

_{* und auch zu spät, um neue Begriffe für REST-ähnliche Nicht-Hypermedia-APIs festzulegen. Wie sollen wir sie überhaupt anrufen? ... RESTISH ?}

Es ist eine CRUD-Schnittstelle (Erstellen, Lesen, Aktualisieren, Löschen) über HTTP.

Ich kann mir keine Behörde vorstellen, die diese Behauptung bestätigt, und hoffe, dass Sie mehr und bessere Antworten erhalten.

Sie können es so nennen, wie Sie möchten. Die Leute tendieren dazu (fast religiös), sich an irgendeinen Teil der REST-Spezifikation zu halten, den Sie nicht befolgen, und verwenden dies als einen Protestpunkt, der der Entwicklung sehr abträglich ist. Die einfache Tatsache ist jedoch, dass es (fast) keine Services gibt, die echten REST für ihre API-Serves implementieren.

In unserem Team haben wir Stateless APIin der Entwicklungsphase unseren Namen angegeben, da wir eine veraltete Stateful- und Functional-SOAP-API hatten, die wir ersetzten (die veraltete API selbst hatte auch nie einen vereinbarten und aussagekräftigen Namen, damit wir uns nicht zu sehr mit Namen beschäftigten ).

Jetzt hat dieses Projekt nur noch eine API, die einfach aufgerufen wird the <project> API. Wenn wir es irgendwann ersetzen, wird die neue API einfach als bekannt sein the new <project> API.

Es ist fast bedeutungslos, ihm einen ausgefallenen und beschreibenden internen Namen zu geben, es sei denn, Sie haben so viele APIs, dass Sie diese von den anderen unterscheiden müssen (in diesem Fall sollten Sie wahrscheinlich auch alle anderen umbenennen).

Sie können es eine Web-API nennen . Es ist ein sehr weit gefasster Begriff, der es jedoch vermeiden kann, sich mit der Bedeutung anderer API-Typdefinitionen auseinanderzusetzen. Der Begriff ist im Vergleich zu Alternativen wie der HTTP-API weniger technisch und präzise. Dies kann jedoch von Vorteil sein, wenn Sie mit nicht-technischen Personen sprechen.

Dieser Begriff wird auch von Leonard Richardson verwendet (der das bereits erwähnte Richardson-Reifegradmodell definiert hat - ein akzeptiertes Maß dafür, wie nahe eine API an einer REST-Architektur liegt). Dies erhalten Sie, wenn Sie den Teil "RESTful" einer " RESTful-Web-API " löschen .