Ich habe eine Ressource namens Pricing , die ich abrufen möchte. Ein Offer kann Preise haben, und ein Promo kann Pricing resource haben, und es gibt eine weitere Entität Customer , mit der Pricing zugeordnet werden kann. Ich möchte Pricing auf Basis von OfferId / PromoId / CustomerId abrufen.
Um die URLs dafür zu entwerfen, habe ich zwei Möglichkeiten:
Option 1: Übergeben Sie es als Abfragezeichenfolge
%Vor%Option 2: Verfügen über drei APIs
%Vor% IMO, OfferId / PromoId / CustomerId sollte als Attribut der Ressource behandelt werden. Daher übergeben Attribut als Abfrage string.Ich bin eher zu Option 1 geneigt.
Option 2 vermeidet, wenn sonst die Bedingung, die Ressource abzurufen und sieht viel sauberer aus, aber scheint es den REST-Standard des URL-Designs zu unterstützen?
Wie lautet der REST-Standard zum Entwerfen der URL? Welche Option würden Sie empfehlen?
Der Weg, der am saubersten wäre und der Standardpfadierung folgt, wäre:
%Vor% Mit dem Layout: /pricing/${offer|promo|customer|/${PathParamForId}
Was Sie dann als drei getrennte Methoden jeweils für Angebot / Werbung / Kunde tun könnten.
Dann müssen Sie nur sicherstellen, dass Ihre API gut dokumentiert ist, damit Benutzer die erwarteten Verhaltensweisen für die Pfade kennen. (Unterschied zwischen Angebot vs Promo-Lookup und etc.)
Ich bevorzuge die Option 1.
Die Option 2 weist die folgenden Mängel auf:
/pricing/offer/234 zu sein
stellen eine Offer Ressource dar, nicht eine Pricing Ressource. Offer Ressource eine Pricing , aber
/pricing/offer/234 repräsentieren im Gegenteil Gegenteil. Es scheint
Wie eine Pricing Ressource enthält eine Offer Ressource. Eigentlich hat die Option 1 auch einige Probleme. zum Beispiel
%Vor%bekommt drei Preise, oder? Es scheint
%Vor%ist vernünftiger.
Eine weitere Option, über die Sie nachdenken können, ist Option 3:
%Vor%hoffe es hilfreich.
Dies wird bereits von @Freedom vorgeschlagen, aber ich denke, es verdient eine eigene Antwort und Begründung.
Sie möchten eine Preisfindung abrufen - aber das bedeutet nicht, dass Sie die URL mit pricing starten müssen.
Promo , Offer und Customer sehen wie Ressourcen aus. Sie haben wahrscheinlich ihre eigenen URLs wie offer/123 . Auch wenn sie keine URLs haben, scheinen sie dennoch ein logisches Container- / Kompositionselement von Pricing zu sein. Also sollte ein Pricing eine Unterressource von diesen sein.
Wenn eine Preisangabe auch eine eigene ID hat, können Sie noch eine weitere Möglichkeit hinzufügen, um alle Preisangaben aufzulisten oder nach dieser ID zu erhalten:
%Vor%