Best Practices für die Verwendung von URIs als Parameterwert in REST-Aufrufen

Question

Ich entwerfe eine REST-API, in der einige Ressourcen über Abfrageparameter gefiltert werden können. In einigen Fällen wären diese Filterwerte Ressourcen von derselben REST-API. Dies führt zu länglichen und ziemlich unlesbaren URIs. Obwohl dies an sich kein allzu großes Problem darstellt, da die URIs programmgesteuert erstellt und manipuliert werden sollen, ist dies ein mühsames Debugging. Ich dachte daran, Verknüpfungen zu URIs zuzulassen, die als Filterwerte verwendet werden, und ich frage mich, ob dies gemäß der REST-Architektur erlaubt ist und ob es Best Practices gibt.

Zum Beispiel:

Ich habe eine Ressource, die mir Java-Klassen wird. Dann wurde die folgende Anfrage würde mir alle Java-Klassen:

GET http://example.org/api/v1/class 

Angenommen, ich möchte, dass alle Unterklassen der Collection Java-Klasse, dann würde ich die folgende Anforderung verwenden:

GET http://example.org/api/v1/class?has-supertype=http://example.org/api/v1/class/collection 

Dieser Antrag zurückkehren würde mich Vector , ArrayList und alle anderen Unterklassen der Java-Klasse Collection.

Diese URI ist jedoch ziemlich lang. Ich könnte es bereits kürzen, indem ich hs als ein Alias ​​für has-supertype erlaubte. Das würde mir geben:

Eine andere Möglichkeit, kürzere URIs zu ermöglichen, wäre, Aliase für URI-Präfixe zu erlauben. Zum Beispiel könnte ich class als Alias ​​für das URI-Präfix http://example.org/api/v1/class/ definieren. Welche mir folgende Möglichkeit geben würde:

GET http://example.org/api/v1/class?hs=class:collection 

Eine weitere Möglichkeit, die Klasse alias vollständig zu entfernen wäre und immer mit http://example.org/api/v1/class/ den Parameterwert Präfix, da dies die einzige Sache ist, würde ich unterstützen. Dies würde die Anforderung für alle Subtypen von Collection in drehen:

GET http://example.org/api/v1/class?hs=collection 

Haben diese „Vereinfachungen“ der ursprünglichen Anforderung URI entsprechen nach wie vor zu den Prinzipien einer REST-Architektur? Oder bin ich einfach aus dem tiefen Ende gegangen?

ADDENDUM: Es kann mehrere URI-Filter gleichzeitig geben. Entweder als unterschiedliche Parameter oder als Liste von Werten für einen einzelnen Parameter. Denken Sie entlang der Zeilen "Alle Klassen, die Interface X und/oder Schnittstelle Y implementieren" oder "Alle Klassen, die Interface X implementieren und im Paket ABC sind" (wobei Pakete auch an einen URI adressierbar wären)

Answer 1

ich würde gehen für die Herstellung:

GET http://example.org/api/v1/class/java.util.Collection/subclasses 

Rückkehr einer Liste von Links zu anderen Einträgen in Ihrem RESTful API, einem für jede direkte Unterklasse. Ich würde auch die Informationen zur Verfügung stellen als Teil des Deskriptors zurückgegeben durch: (. Das wäre auch ein Link auf die vorhergehenden spezifischen Abfrage)

GET http://example.org/api/v1/class/java.util.Collection