Gibt es eine Möglichkeit, alle Endpunkte einer REST-API zu erkennen?

Ich frage mich, ob es möglich ist, alle Endpunkte einer bestimmten API programmgesteuert zu erkennen.

Also zum Beispiel, wenn ich diese URL mit einem Browser oder Curl ERHALTE:
https://api.twitter.com/1.1/

Ich könnte so etwas als JSON-Antwort erhalten:

"TwitterAPI":{
    "version" : 1.1,
    "GET" : {
        "search/" : ["users", "trending"],
        "users/" : ["id", "handle"]
    }
}

Natürlich könnte Twitter dieses Format veröffentlichen oder nicht veröffentlichen. Also als Randfrage, gibt es Bibliotheken für Java oder JavaScript, die automatisch die API-Routen abbilden und veröffentlichen, die Sie in Ihren Controllern erstellt haben?

Es gibt keine Möglichkeit, REST-Dienste programmgesteuert zu erkennen, da sie keinen Standardregistrierungsdienst haben.

Abgesehen von einer verrückten Brute-Force-Suche gibt es keine Möglichkeit, die richtigen URLs zu finden (ganz zu schweigen von den richtigen Parametern). Die einzige Möglichkeit besteht also darin, Ihre API zu dokumentieren. Dafür ist die beste Wahl, die ich bisher gesehen habe:

• Stolzieren
• Und die Leute mögen auch API-Blaupause.

Einige RESTful-APIs veröffentlichen eine Web Application Description Language-Ressource (WADL – ausgesprochen wie the walk that ducks do – kurz). JAX-RS oder zumindest Jersy-Webapps tun dies standardmäßig unter der Anwendungsstamm-URL /application.wadl. Es scheint nicht, dass die API von Twitter eine davon ist. Viele REST-Puristen würden argumentieren, dass die API selbstbeschreibend und selbstentdeckbar sein sollte, indem sie einfach mit ihr interagieren und sehen, welche anderen Endpunkte sie Ihnen geben wird.

Mehr über WADL von Wikipedia…

Sie sollten in der Lage sein, alles zu entdecken, was Sie über eine REST-API wissen müssen, indem Sie nur den anfänglichen Einstiegspunkt kennen. Dies ist einer der grundlegenden Punkte von REST; dass es hypermedia-gesteuert und selbstbeschreibend sein sollte. Es ist auch eines der am wenigsten verstandenen Prinzipien. Die Entdeckung von Ressourcen erfolgt über Hypermedia-Links in den Antworten des Servers.

Zurück so lange her wie 2008 begann sich Roy Fielding darüber zu ärgern, dass Leute HTTP-basierte APIs schreiben und sie REST nennen nur weil es das heiße neue Ding war. Hier sind ein paar Punkte, die er macht;

Eine REST-API dürfen keine festen Ressourcennamen oder Hierarchien definieren (eine offensichtliche Kopplung von Client und Server). Server müssen die Freiheit haben, ihren eigenen Namensraum zu kontrollieren. Erlauben Sie stattdessen Servern, Clients anzuweisen, wie geeignete URIs zu erstellen sind, wie dies in HTML-Formularen und URI-Vorlagen der Fall ist, indem Sie diese Anweisungen innerhalb von Medientypen und Linkbeziehungen definieren. [Failure here implies that clients are
assuming a resource structure due to out-of band information, such as
a domain-specific standard, which is the data-oriented equivalent to
RPC’s functional coupling].

und

Eine REST-API sollten ohne Vorkenntnisse über die anfängliche URI (Lesezeichen) und eine Reihe von standardisierten Medientypen, die für die beabsichtigte Zielgruppe geeignet sind, eingegeben werden (dh es wird erwartet, dass es von jedem Client verstanden wird, der die API verwenden könnte). Von diesem Punkt an müssen alle Anwendungszustandsübergänge durch die Client-Auswahl von vom Server bereitgestellten Auswahlmöglichkeiten gesteuert werden, die in den empfangenen Darstellungen vorhanden sind oder durch die Manipulation dieser Darstellungen durch den Benutzer impliziert werden. Die Übergänge können durch das Wissen des Clients über Medientypen und Ressourcenkommunikationsmechanismen bestimmt (oder begrenzt) werden, die beide spontan verbessert werden können (z. B. Code-on-Demand). [Failure here implies that out-of-band information is
driving interaction instead of hypertext.]

In der Praxis bedeutet dies, dass der Einstiegspunkt (der normalerweise den Stamm-URI von „https://stackoverflow.com/“ verwendet) Links zu anderen REST-APIs enthält. Diese APIs enthalten Links zu anderen APIs und so weiter. Es sollte keine API geben, die keinen Link darauf hat. Das würde bedeuten, dass es nicht auffindbar ist.

Die anderen Antworten hier sind grundlegend falsch, da sie das grundlegendste Prinzip von REST nicht anerkennen.

Es gibt eine Möglichkeit, die meisten versteckten REst-Apis von innerhalb der Website zu erhalten. Folgen Sie dieser Dokumentation.