2016-09-18 4 views
3

Je suis très novice dans la mise en œuvre de l'API et j'avais besoin de conseils sur la meilleure ou la meilleure approche de ma structure d'API.Routeurs imbriqués vs filtres

Actuellement ma mise en œuvre comprend des routeurs imbriqués (routeurs DRF-imbriqués-paquet) tels que

"www.thissite.com/store/21/products/1/"

Maintenant que je creuse plus profondément dans django J'ai découvert qu'il ya des filtres qui me permettent de faire la même opération exacte ci-dessus avec un peu moins de code comme celui-ci

« id = www.thissite.com/products/?store__id=21 & 1 »

Ma question est celle qui est meilleure pratique et pourquoi?

Répondre

0

Si un produit est toujours associé à un magasin (ce qui semble être le cas, étant donné les noms), il est recommandé à REST de maintenir une structure hiérarchique en créant une sous-ressource de stores. Ainsi, je vous suggère de suivre la première approche mentionnée ci-dessus.

Le filtrage doit être utilisé pour filtrer les ressources en fonction de certaines caractéristiques internes (par exemple, les attributs de classe), non basées sur les relations avec d'autres ressources.

+0

Merci, je vais le faire :) –

0

Les deux sont les meilleures pratiques, car REST ne contraint pas la conception d'URI. J'appelle www.thissite.com/store/21/products/1/ conception d'URI hiérarchique et www.thissite.com/products/?store__id=21&id=1 conception d'URI plat. J'aime mieux le design plat, mais c'est juste mon goût personnel. Si vous avez besoin à la fois store-id et product-id afin d'identifier un produit alors ces URI sont correctes et tous les URI sont corrects avec ces variables, par exemple x/y/z/:pid/q/r/s/:sid, etc ... Par REST la création d'URI (template) est sous la responsabilité du service et les clients ne consomment que les URI qu'il reçoit du service sous forme de liens hypertexte. Du point de vue du client REST, la structure de l'URI n'a donc aucune importance. Nous avons tendance à concevoir des URI symétriques uniquement pour maintenir la logique de routage du service REST.