Müssen REST-API-URLs so aussehen?

Question

Stimmt es, dass man zur Implementierung einer RESTful API eine URL-Struktur implementieren muss, die wie folgt aussieht

http://example.com/post/
http://example.com/post/123

wo die /123 würde für Bearbeiten, Löschen

Eine andere Möglichkeit, die Frage zu stellen, ist: Kann eine URL, die so aussieht, als RESTful bezeichnet werden?

http://example.com/script.php?method=get_title&blogid=123

Answer 1

Sie haben keine haben um Ihre URI-Struktur so zu gestalten. Es könnte auch sein /some_obscure_string/base64_encoded_title/unique_id . Dies könnte auch RESTful sein, abhängig von verschiedenen anderen Faktoren.

Es gibt jedoch mehrere bewährte Verfahren für die Gestaltung von URIs in einer RESTful-Webanwendung, und eines davon ist, dass sie so einfach und so gut lesbar wie möglich sein sollten.

Ihr Beispiel http://example.com/script.php?method=get_title&blogid=123 könnte auch RESTful sein, aber die Abfrageparameter weisen darauf hin, dass stattdessen eine Art RPC- oder RMI-over-HTTP verwendet wird.

Um es zusammenzufassen: Machen Sie sich nicht zu viele Gedanken über Ihr URI-Design. Das ergibt sich automatisch bei einem guten und richtigen RESTful-Design Ihrer Anwendung.

Answer 2

Die Idee hinter REST ist, dass jede Ressource ihre eigene URL hat und Sie die verschiedenen HTTP-Methoden verwenden, um mit diesen Ressourcen zu interagieren. Es ist sinnvoll, die URL-Struktur so zu definieren, dass die Hierarchie zwischen den verschiedenen Ressourcen in der URL widergespiegelt wird, aber das ist nicht notwendig.

Wenn Sie URLs wie diese haben

 /all-posts/
 /first-post
 /some-stuff/second-post
 /third-post

könnten Sie dennoch eine RESTful API dafür bereitstellen. Die Idee ist, dass eine GET a /all-posts/ gibt eine Liste der URLs aller Post-Objekte zurück, und der Client verwendet diese URLs, um mit den Ressourcen zu interagieren. Grundsätzlich sollten die URLs vom Client als undurchsichtige Daten behandelt werden.

Solange sich die in den Client eingebettete URL nicht ändert, können Sie auch die Struktur ändern, ohne den Client ändern zu müssen.

Ihre Beispiel-URL gehört wahrscheinlich nicht zu einer RESTful-API, denn sie enthält eine Methode get_title . Bei REST stellt eine URL eine Sache . Was mit dem Ding gemacht werden soll (soll es verändert werden, soll sein Inhalt abgerufen werden, ...) ist nicht Teil der URL, dafür verwendet REST die verschiedenen HTTP-Methoden.

Answer 3

Ein wichtiger Aspekt von REST ist, dass die URL die Ressource ist. eine URL wie

http://example.com/script.php?etc-etc-etc

setzt den Ressourcenkennzeichner nicht in den Ressourcenteil der Uri. Das soll nicht heißen, dass eine RESTful-API niemals Get-Parameter verwenden sollte; das ist sogar völlig in Ordnung:

http://example.com/posts?sort=date_asc&offset=20&limit=10

könnte eine gute Möglichkeit sein, die URIs der 3. Seite der ältesten Beiträge zu erhalten. Die Verwendung von get-Parametern auf diese Weise sollte jedoch nur in Anfragen verwendet werden, bei denen die Methode auch GET . PUT und insbesondere POST Methoden sollten wirklich einfache uri's mit der Ressource, die nur im Pfadteil betroffen sein wird, verwenden.

Answer 4

Bei der Gestaltung von RESTful-URIs geht es um den Zugriff auf Ressourcen, und diese sollten auf RESTful-Art strukturiert sein, d. h. es sollten keine Abfragezeichenfolgen vorhanden sein.

z.B. von GET

Autoren/

Autoren/1

Autoren/1/Bücher

Autoren/1/Bücher/10

autoren/1/buecher/10/zusammenfassung

usw.

Heutzutage wird alles und jedes als RESTfull bezeichnet. Schauen Sie sich nur einige der Antworten seines Erfinders Dr. Roy Fielding an, und Sie werden einige Ideen bekommen. Es lohnt sich, etwas über dieses Thema zu lesen.

P.S. Sie brauchen post, get usw. nicht in Ihren URIs, das HTTP-Protokoll wird derzeit hauptsächlich für die Nutzung von REST-APIs verwendet und Sie können Verb als Teil des Aufrufs übergeben. Außerdem gibt es ein Konzept der Inhaltsaushandlung, d. h. Sie können jedes verfügbare Format von der REST-API anfordern (json, xml usw.).

Answer 5

Beispiel-URLs:

GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]