Le RESTful api est sur l'affichage d'une ressource basée sur une structure (répertoire-comme la structure, la date: les articles/2005/5/13, objet et attributs,..), la barre oblique indique une structure hiérarchique, utilisez l'id de la place.
Structure hiérarchique
Personnellement, je préfère:
/garage-id/cars/car-id
/cars/car-id #for cars not in garage
Si un utilisateur supprime l' /car-id partie, il apporte l' cars preview - intuitive. L'utilisateur sait exactement où dans l'arbre qu'il est, ce qu'il recherche. Il sait dès le premier regard, que les garages et les voitures sont en relation. /car-id indique aussi qu'il appartient, ensemble, à la différence de /car/id.
La recherche
Le searchquery est bien comme il est, il est seulement votre préférence, ce qui devrait être pris en compte. Le plus drôle vient lors de l'adhésion des recherches (voir ci-dessous).
/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 #I don't recommend using &*
Ou de manière générale tout ce qui n'est pas un slash comme expliqué ci-dessus.
La formule: /cars[?;]color[=-:]blue[,;+&], * bien que je ne voudrais pas utiliser l' & signe qu'il est méconnaissable dans le texte au premier coup d'œil.
** Saviez-vous que le passage d'objet JSON dans URI est Reposante? **
Des listes d'options
/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
les fonctionnalités possibles?
Nier les chaînes de recherche (!)
Pour rechercher toutes les voitures, mais pas en noir et rouge:
?color=!black,!red
color:(!black,!red)
Rejoint les recherches
De recherche, de rouge ou de bleu ou de noir les voitures avec 3 portes de garages id 1..20 ou 101..103 ou 999 , mais pas 5
/garage[id=1-20,101-103,999,!5]/cars[color=red,blue,black;doors=3]
Vous pouvez alors construire plus complexes, les requêtes de recherche. (Regardez CSS3 attribut correspondant à l'idée de sous-chaînes correspondantes. E. g. la recherche des utilisateurs contenant "bar" user*=bar.)
Conclusion
De toute façon, cela peut être la partie la plus importante pour vous, parce que vous pouvez faire comme bon vous semble, après tout, il suffit de garder à l'esprit que Reposant URI représente une structure qui est facile à comprendre, par exemple, l'annuaire comme /directory/file, /collection/node/item ou d'une autre règle n' /articles/{year}/{month}/{day} et par ommiting le dernier segment, vous savez ce que vous obtenez.
Alors.., tous ces caractères sont autorisés clair:
- sans réserve:
a-zA-Z0-9_.-~
- réservés:
;/?:@=&$-_.+!*'(),
- dangereux*:
<>"#%{}|\^~[] ` <-ça, c'est dangereux aussi ^^
*Pourquoi dangereux et pourquoi devrait plutôt être codé: RFC 1738 voir 2.2
RFC 3986 voir 2.2
En dépit de ce que j'ai dit précédemment, ici, est une commune de la distinction, ce qui signifie que certains délimiteurs", sont " de plus en plus important.
- générique délimiteurs:
:/?#[]@
- sous-délimiteurs:
!$&'()*+,;=
Plus de lecture:
Hiérarchie: voir la section 2.3, voir 1.2.3
chemin d'accès d'url syntaxe de paramètre
CSS3 attribut correspondant
IBM: les services Web RESTful - notions de base
Remarque: la RFC 1738 a été mis à jour par la RFC 3986
