RESTful URL-Design für die Suche

Question

Ich bin auf der Suche nach einer vernünftigen Möglichkeit, Suchen als RESTful URLs darzustellen.

Der Aufbau: Ich habe zwei Modelle, Autos und Garagen, wobei Autos in Garagen sein können. Meine URLs sehen also so aus:

/car/xxxx
  xxx == car id
  returns car with given id

/garage/yyy
  yyy = garage id
  returns garage with given id

Ein Auto kann allein stehen (daher das /car), oder es kann in einer Garage stehen. Wie kann man nun alle Autos in einer bestimmten Garage darstellen? Etwa so:

/garage/yyy/cars     ?

Wie wäre es mit der Vereinigung der Autos in Garage yyy und zzz?

Wie kann man eine Suche nach Autos mit bestimmten Eigenschaften richtig darstellen? Sprich: Zeige mir alle blauen Limousinen mit 4 Türen:

/car/search?color=blue&type=sedan&doors=4

oder sollte es stattdessen /cars heißen?

Die Verwendung von "Suche" scheint hier unangebracht zu sein - was ist ein besserer Weg / Begriff? Sollte es einfach sein:

/cars/?color=blue&type=sedan&doors=4

Sollten die Suchparameter Teil des PATHINFO oder QUERYSTRING sein?

Kurz gesagt, ich suche eine Anleitung für die modellübergreifende Gestaltung von REST-Url und für die Suche.

[Update] Ich mag Justins Antwort, aber er deckt nicht den Fall der Suche mit mehreren Feldern ab:

/cars/color:blue/type:sedan/doors:4

oder etwas Ähnliches. Wie kommen wir von

/cars/color/blue

auf den Fall mit mehreren Feldern?

Answer 1

Obwohl mir Justins Antwort gefällt, bin ich der Meinung, dass sie eher einem Filter als einer Suche entspricht. Was ist, wenn ich etwas über Autos wissen möchte, deren Namen mit "Cam" beginnen?

So wie ich das sehe, könnte man das in die Art und Weise einbauen, wie man mit bestimmten Ressourcen umgeht:
/autos/cam*

Oder Sie können sie einfach in den Filter einfügen:
/autos/tueren/4/name/cam*/farben/rot,blau,grün

Ich persönlich bevorzuge letzteres, bin aber keineswegs ein Experte für REST (ich habe erst vor etwa 2 Wochen zum ersten Mal davon gehört...)

Answer 2

Mein Ratschlag wäre der folgende:

/garages
  Returns list of garages (think JSON array here)
/garages/yyy
  Returns specific garage
/garage/yyy/cars
  Returns list of cars in garage
/garages/cars
  Returns list of all cars in all garages (may not be practical of course)
/cars
  Returns list of all cars
/cars/xxx
  Returns specific car
/cars/colors
  Returns lists of all posible colors for cars
/cars/colors/red,blue,green
  Returns list of cars of the specific colors (yes commas are allowed :) )

Edita:

/cars/colors/red,blue,green/doors/2
  Returns list of all red,blue, and green cars with 2 doors.
/cars/type/hatchback,coupe/colors/red,blue,green/
  Same idea as the above but a lil more intuitive.
/cars/colors/red,blue,green/doors/two-door,four-door
  All cars that are red, blue, green and have either two or four doors.

Ich hoffe, das gibt Ihnen einen Eindruck. Im Wesentlichen sollte Ihre Rest-API leicht auffindbar sein und es Ihnen ermöglichen, Ihre Daten zu durchsuchen. Ein weiterer Vorteil der Verwendung von URLs und nicht von Query-Strings ist, dass Sie die Vorteile der nativen Caching-Mechanismen nutzen können, die auf dem Webserver für den HTTP-Verkehr vorhanden sind.

Hier ist ein Link zu einer Seite, die die Übel von Query-Strings in REST beschreibt: http://web.archive.org/web/20070815111413/http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful

Ich habe den Cache von Google benutzt, weil die normale Seite nicht funktioniert hat. Hier ist der Link: http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful