Les RESTful hübsches URL-Design geht es um die Anzeige einer Ressource auf der Grundlage einer Struktur (verzeichnisartige Struktur, Datum: Artikel/2005/5/13, Objekt und seine Attribute, ), der Schrägstrich / eine hierarchische Struktur anzeigt, verwenden Sie die -id stattdessen.
Hierarchische Struktur
Ich persönlich würde es vorziehen:
/garage-id/cars/car-id
/cars/car-id #for cars not in garages
Entfernt ein Benutzer die /car-id Teil, es bringt die cars Vorschau - intuitiv. Der Benutzer weiß genau, wo im Baum er sich befindet und was er sieht. Er weiß auf den ersten Blick, dass Garagen und Autos in Beziehung zueinander stehen. /car-id bedeutet auch, dass es zusammengehört, im Gegensatz zu /car/id .
Suche auf
Die Suchabfrage ist so, wie sie ist, in Ordnung Es ist nur Ihre Vorliebe, die berücksichtigt werden sollte. Der witzige Teil kommt, wenn man die Suche verbindet (siehe unten).
/cars?color=blue;type=sedan #most prefered by me
/cars;color-blue+doors-4+type-sedan #looks good when using car-id
/cars?color=blue&doors=4&type=sedan #also possible, but & blends in with text
Oder grundsätzlich alles, was kein Schrägstrich ist, wie oben erklärt.
Die Formel: /cars[?;]color[=-:]blue[,;+&] Ich würde allerdings nicht die & Zeichen, da es auf den ersten Blick nicht vom Text zu unterscheiden ist, falls das Ihr Ding ist.
** Wussten Sie, dass die Übergabe eines JSON-Objekts in einem URI RESTful ist? **
Listen von Optionen
/cars?color=black,blue,red;doors=3,5;type=sedan #most prefered by me
/cars?color:black:blue:red;doors:3:5;type:sedan
/cars?color(black,blue,red);doors(3,5);type(sedan) #does not look bad at all
/cars?color:(black,blue,red);doors:(3,5);type:sedan #little difference
mögliche Merkmale?
Suchstrings negieren (!)
Zur Durchsuchung beliebiger Fahrzeuge, aber no schwarz y rot :
?color=!black,!red
color:(!black,!red)
Gemeinsame Suche
Suche rot o blau o schwarz Autos mit 3 Türen in Garagen id 1..20 o 101..103 o 999 pero no 5 /garage[id=1-20,101-103,999,!5]/cars[color=red,blue,black;doors=3]
Sie können dann komplexere Suchanfragen formulieren. (Sehen Sie sich CSS3-Attribut-Abgleich für die Idee des Abgleichs von Teilzeichenfolgen. Z.B. Suche nach Benutzern, die "bar" enthalten user*=bar .)
Schlussfolgerung
Dies ist vielleicht der wichtigste Teil für Sie, denn Sie können es tun, wie Sie wollen, aber bedenken Sie, dass RESTful URI stellt eine leicht verständliche Struktur dar, z. B. eine verzeichnisartige /directory/file , /collection/node/item Daten /articles/{year}/{month}/{day} .. Und wenn Sie eines der letzten Segmente weglassen, wissen Sie sofort, was Sie bekommen.
Also, all diese Figuren sind unverschlüsselt erlaubt :
- ohne Vorbehalt:
a-zA-Z0-9_.-~
In der Regel sind beide Verwendungen, verschlüsselt und unverschlüsselt, gleichwertig.
- Sonderzeichen:
$-_.+!*'(),
- reserviert:
;/?:@=&
Sie können für den Zweck, den sie darstellen, unverschlüsselt verwendet werden, andernfalls müssen sie verschlüsselt werden.
- unsicher:
<>"#%{}|^~[]`
Warum unsicher und warum sollte lieber verschlüsselt werden: RFC 1738 siehe 2.2
Siehe auch RFC 1738#Seite-20 für weitere Charakterklassen.
RFC 3986 siehe 2.2
Ungeachtet dessen, was ich zuvor gesagt habe, gibt es hier eine gemeinsame Unterscheidung von Abgrenzungen, was bedeutet, dass einige "sind" wichtiger sind als andere.
- generische Begrenzungszeichen:
:/?#[]@
- Sub-Delimeter:
!$&'()*+,;=
Lesen Sie weiter:
Hierarchie: siehe 2.3 , siehe 1.2.3
url pfad parameter syntax
CSS3-Attribut-Abgleich
IBM: RESTful Web Services - Die Grundlagen
Hinweis: RFC 1738 wurde durch RFC 3986 aktualisiert.
17 Stimmen
Obwohl es auf Englisch besser aussieht, mischen
/carsy/carist nicht semantisch und daher eine schlechte Idee. Verwenden Sie immer den Plural, wenn es mehr als einen Artikel unter dieser Kategorie gibt.5 Stimmen
Dies sind schlechte Antworten. Die Suche sollte Abfragezeichenfolgen verwenden. Abfragezeichenfolgen sind 100% RESTful, wenn sie richtig verwendet werden (dh für die Suche).
2 Stimmen
Auschecken doriantaylor.com/policy/http-url-path-parameter-syntax