Je travaille sur une API privée pour notre backend.
J'ai des collections qui ont des associations.
Chaque collection peut être demandée, paginé, vous pouvez également demander les associations et paginer ces associations.
Nous ne sommes pas sûrs de la conception de l'URL à utiliser ... Nous pensons:
/users.json?per_page=10&association=Parts,autions&partts_per_page=5&auditions_per_page=5
/users.json?per_page=10&association [] = Pièces et association [] = Auditions & Pièces_per_page = 5 & Auditions_PER_PAGE = 10
/users.json?per_page=10&association [Auditions] = True & Association [Pièces] [PER_PAGE] = 5
Que pensez-vous? Lequel choisiriez-vous? Pourquoi ? Est-ce que l'une d'entre elles ne ressemble-t-elle pas à des systèmes d'URL valides?
Merci!
3 Réponses :
Il y a beaucoup de postes utiles sous le étiquette reposante-url .
Certains postes utiles:
Les URL de l'API de repos doivent-elles ressembler à ceci? < / a>
meilleures pratiques sur l'utilisation de URI comme paramètre Valeur dans les appels de repos.
Hey Marcus, merci pour le suivi et pour le marquer à l'URL reposante, je n'ai trouvé aucun message utile sur l'utilisation de tableaux dans une API. Et je ne suis pas sûr que cette API puisse être classée de manière reposante, nous ne voulions pas tout nier ... Sinon pour obtenir 2 associations d'une collection que nous devrions faire 2 appels et nous ne voulons pas vraiment cette.
J'irais pour la 1ère. Je n'aime pas voir la notation [] sur l'URL, IMHO, il rend plus difficile le client de l'utiliser et de comprendre. Quelques changements comme suggestions.
1) Comme l'association semble être un tableau, changer les associations (pluriel, si j'ai raison et c'est un tableau)
2) Vous pouvez également essayer de mettre un Per_Page par défaut et une option facultative, même agrégant, quelque chose comme Per_Page_Parts_auditions au lieu d'utiliser Per_Page_Parts et Per_Page_auditions. Je ne le ferais pas si votre API avait été conçue pour être public, car il est plus facile à utiliser, mais plus difficile à comprendre, mais comme vous l'avez posté, il est privé .. devrait être un bon moyen d'éviter la réplication.
1 / d'accord (c'est un éventail de collections..stiquement des relations SQL) 2 / Il y a déjà une valeur par défaut Per_Page (vous n'avez pas besoin de le définir, mais vous pouvez également - il y a aussi {association} _per_page par défaut, je voulais juste vous montrer une utilisation. Cas) Et je ne peux pas vraiment utiliser un per_page_parts_auditions depuis que je ne vous montre que 2 associations, mais en fait, il y a beaucoup plus de choses et j'ai des tonnes de collections différentes (toutes avec différentes associations). Nos arguments {association} _per_page sont générés de manière dynamique.
Comme vos arguments {association} _per_page sont générés de manière dynamique, vous ne pouvez pas le faire {associations} _per_page et sur votre code appelez les codes {association} _per_page?
Désolé je ne reçois pas cette dernière question, je demande déjà {association} _per_page ..
Ma réponse: Squid, par exemple, est un cache HTTP populaire que par défaut ne cache aucune URL qui a une querystring. De plus, de nombreux clients et même serveurs et intermédiaires génèrent et consomment des paramètres de chaîne de requête dans une commande indéfinie; C'est-à-dire, "? A = 3 & B = 5" peut être réécrit arbitrairement comme "? B = 5 & A = 3". Toutefois, pour la mise en cache HTTP, la commande compte et les deux pages seront mises en cache séparément même s'ils ont le même contenu. Lorsque vous ajoutez des paramètres, ce problème augmente de manière exponentielle.
Vous devez concevoir vos ressources (et leurs représentations) pour tirer parti de la mise en cache de deux techniques opposées mais complémentaires:
Dans votre cas, ÉTAPE 1 implique de combiner des associations et des pièces dans la représentation "Utilisateurs", sans aucune option pour le client de configurer lesquelles et combien. Cela vous permettra de cacher de manière agressive la représentation de la réponse unique sans surcharger vos caches (et de leurs) en caches avec une explosion combinatoire de réponses en raison de toutes les options de QueryString.
L'étape 2 implique de séparer Alors vos utilisateurs crieront "mais c'est 10 fois le trafic réseau!" À laquelle vous répondez calmement, "Non, c'est 1 / 10ème du trafic réseau, car 9 fois sur 10 Les ressources demandées sont déjà assis dans le cache de votre client (navigateur) (et quand ils ne sont pas, c'est 1 / 10ème Les ressources de calcul du serveur depuis qu'ils sont assises dans un cache côté serveur, et quand ils ne sont pas là non plus, nous évitons de tamponner avec un cache intelligent sur le serveur). "
Bien sûr, si la ressource /users.json . HTTP est optimisé pour le transfert hypermédia à gros grains; La mise en cache en fait une grande partie de cela, et aucun des systèmes URI n'est indiqué ci-dessus ne sont très respectueux de la cache.
/users.json dans des entités "utilisateur" distinctes, chacune avec une ressource "associations" et une ressource "pièces". Donc / users / {id} et / users / {id} / associations et / utilisateurs / {id} / pièces . La ressource "/ utilisateurs" renvoie ensuite une gamme de ressources hyperliens vers les ressources "/ utilisateurs / {id}" et chaque "/ utilisateur / {id}` "La représentation contient des hyperliens à ses associations et à ses parties (cette partie est plus malléable- -Il pourrait mieux adapter votre application à intégrer les associations et les pièces dans la ressource utilisateur directement). Cela vous permettra de cacher agressivement la réponse à chaque ressource "en demande" sans avoir à cacher toute votre base de données.
/ utilisateurs est un million de nouveaux visiteurs touchent tous les jours, votre chemin d'optimisation pourrait être différent. Mais cela ne semble pas si basé sur vos exemples de programmes URI.
Hey Fumanchu, merci pour la réponse! Je ne comprends pas pourquoi mes URL ne sont pas optimisées pour le cache? Ces appels ne seront pas effectués dans un navigateur mais le côté serveur (je peux facilement mettre en cache en fonction des paramètres URL +). Je ne veux pas séparer les appels à chaque association (c'est pourquoi mon API n'est pas totalement reposante), cela signifierait de faire plusieurs appels pour obtenir des informations et je n'ai même pas de cache ...
J'ai ajouté ma réponse à l'intérieur de ma réponse ci-dessus (en italique).