J'ai une question sur la syntaxe REST: quelle URL donnez-vous à un point de terminaison pour extraire des données similaires à l'enregistrement qui à partir de l'identifiant passé?
Par exemple: j'ai une classe Record: Enregistrez {id: 12, phoneNumber: "+ 336746563"}
Je veux un point de terminaison qui renverra tous les enregistrements qui partagent le même numéro de téléphone que l'enregistrement avec l'ID 12
Quelle URL respecte le plus le protocole REST?
MODIFIER IMPORTANT: le client NE connaît PAS le numéro de téléphone lorsqu'il appelle l'url. seulement le 12 id.
3 Réponses :
Je ne suis pas sûr si je comprends la question mais laissez-moi essayer.
Vous pouvez le faire de différentes manières qui vous convient le mieux pour vous W.R.T. votre langage de programmation. Par exemple, Alternativement, le point final peut être ou même, L'autre option consiste à avoir les données de demande dans le corps et que le domaine ressemblerait à afaik, toutes ces URL respectent le protocole de repos. domain.com/api/records/123456 peut être le point final. 123456 est un paramètre et votre code retournera tous les enregistrements ayant Phonenumumber = 123456.
domain.com/api/records?phonenumber=12345 .
domain.com/api/records/123456/blonenchumber .
domain.com/api/records avec demande comme {"phonenumber": "123456" }
"obtenir" dans une URL?
Ouais, mon mauvais. Édité. Merci @sschrass
vous savez que les données dans le corps ne vont pas avec GET-Requets?
Totalement. Je n'ai spécifié le type d'appel pour aucun point final. On suppose que celui du corps sera de type POST. L'intention de la question est de concevoir le point final.
le client ne connaît pas le numéro de téléphone lorsqu'il appelle mon URL de repos.
N'importe lequel de mes points de terminaison ou de @sschrass suffirait. Tout ce que vous avez à faire est de dériver le numéro de téléphone de l'identifiant dans la demande, de trouver tous les identifiants (ou enregistrements) et de revenir.
J'utiliserais quelque chose comme
/service/records/phone-number/12345
où le service définirait la similarité. Cela dépend des cas d'utilisation pour lesquels Record devient plus complexe et que le client doit pouvoir spécifier des champs.
Cela entraînerait tôt ou tard des requêtes qui ne seraient pas basées sur un enregistrement existant et à mon apparence
/service/records?foo=1&bar=2
Je pourrais aussi penser à
/service/records/{id}/similar
le client ne connaît pas le numéro de téléphone lorsqu'il appelle mon URL de repos.
bien sûr qu'il le fait! Il obtient juste le disque avec l'identifiant qu'il a.
Dans mon cas d'utilisation, ce n'est pas vraiment un numéro de téléphone (je dis que c'est pour l'exemple). Ce sont des données internes auxquelles il ne devrait pas avoir accès, que nous supprimons de la réponse.
ah je vois, alors j'irais avec la première URL. Comme il est caché au client, seul le service le sait.
Quelle URL donnez-vous à un point de terminaison pour extraire des données similaires à l'enregistrement qui à partir de l'identifiant transmis?
Tout ce que vous voulez - les machines ne se soucient pas de l'orthographe que vous utilisez pour vos identifiants de ressources.
Je veux un point de terminaison qui renverra tous les enregistrements qui partagent le même numéro de téléphone que l'enregistrement avec l'ID 12
/record/12/all-records-with-same-phone-numberTous ces exemples sont très bien . Ils ont différents compromis - le premier est vraiment facile à générer à l'aide d'un formulaire HTML. La dernière fois vous permet de faire des choses intéressantes avec des références relatives et des segments de points.
/all-records-with-same-phone-number-as?id=12 /all-records-with-same-phone-number-as?12 /all-records-with-same-phone-number-as/12similaire à ce qui précède, nous venons de jongler un peu l'ordre des segments de chemin . Cela peut être utile si nous voulons avoir des références relatives à d'autres ressources sous la même racine
/ record / 12.Si vous prévoyez avoir besoin de paginer, alors vous voudrez peut-être pensez à la façon dont les paramètres de pagination s'accordent avec tout le reste. Encore une fois, les machines s'en moquent, mais certaines orthographes sont plus faciles à utiliser que d'autres.