Quel est l’avantage des URI de ressources globales (c’est-à-dire l’adressabilité)?
https://stackoverflow.com/questions/147172
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Quel est l'avantage de référencer des ressources à l'aide d'URI uniques au monde (comme le fait REST) ??par rapport à un format d'identifiant propriétaire?
Par exemple:
Dans la première approche, l’URL entière est l’ID. Dans la seconde approche, seul le 5 est l'ID. Quel est l’avantage pratique de la première approche par rapport à la seconde?
Pourquoi REST (semble-t-il) fait tout son possible pour défendre la première approche?
- EDIT:
Ma question était confuse car elle posait en réalité deux questions distinctes:
- Quel est l'avantage de l'adressabilité?
- Quelle est la différence entre les deux formes d'URI décrites ci-dessus.
J'ai répondu aux deux questions ci-dessous en utilisant mon propre message.
La solution 2
Je vais répondre à ma propre question:
1) Pourquoi les URI sont-ils importants?
Je citerai les services Web RESTful de Leonard Richardson et Sam Ruby (ISBN: 978-0-596-52926-0) :
Considérons un URI réel qui nomme une ressource dans le genre "répertoire de ressources sur méduse »: http://www.google.com/search?q=jellyfish . Cette recherche de méduses est juste comme Il s'agit en réalité d'un http://www.google.com . Si HTTP n’était pas adressable, ou si Google moteur de recherche n’était pas une application Web adressable, je ne serais pas en mesure de publier cette URI dans un livre. Je dois vous dire: "Ouvrez une connexion Web sur google.com, tapez" jellyfish " dans le champ de recherche, puis cliquez sur le bouton "Recherche Google".
Ce n’est pas un souci académique. Jusqu'au milieu des années 1990, lorsque ftp: // URI est devenu populaire pour décrire des fichiers sur des sites FTP, les gens devaient écrire Des choses comme: «Démarrer une session FTP anonyme sur ftp.example.com. ensuite allez dans le répertoire pub / files / et téléchargez le fichier fichier.txt. ”URI créés FTP comme adressable comme HTTP. Maintenant, les gens écrivent simplement: “Télécharger ftp: // ftp.example.com/pub/files/file.txt. ”Les étapes sont les mêmes, mais maintenant peut être effectué à la machine.
[...]
L’adressabilité est l’une des meilleures choses à propos des applications Web. Il est facile pour les clients à utiliser les sites Web d'une manière que les concepteurs d'origine n'ont jamais imaginée.
2) Quel est l'avantage de l'adressabilité?
Il est beaucoup plus facile de suivre les URI fournis par le serveur que de les construire vous-même. Cela est d'autant plus vrai que les relations entre ressources deviennent trop complexes pour être exprimées dans des règles simples. Il est plus facile de coder la logique une fois sur le serveur que de la réimplémenter dans de nombreux clients.
La relation entre les ressources peut changer même si les URI de ressources individuelles restent inchangés. Par exemple, si Google Maps devait modifier l’échelle de ses mosaïques, les clients qui calculent la position relative des mosaïques se briseraient.
3) Quel est l'avantage des adresses URI par rapport aux ID personnalisés?
Les identifiants personnalisés identifient une ressource de manière unique. Les URI vont plus loin en vous indiquant où le trouver. Cela simplifie la logique client.
Autres conseils
Lorsque je vois uri comme ça, l’essentiel, c’est qu’un utilisateur normal puisse se souvenir de cette uri.
Les geeks acceptent les points d'interrogation et les variables, mais si quelqu'un se souvient de http: // www. host.com/users/john au lieu de http://www.host. com /? view = users & amp; name = john , c’est un avantage énorme.
Optimisation des moteurs de recherche principalement.
Cela les rend également plus faciles à mémoriser, et plus propres, à mon avis plus professionnels.
Le premier est plus esthétique.
Techniquement, il n'y a pas de différence, mais utilisez l'ancien lorsque vous le pouvez.
Comme & lafur l'a mentionné, la clarté de l'ancienne URL est un avantage.
Une autre solution est la flexibilité de la mise en œuvre.
Supposons que l’étudiant 5 change rarement. Si vous utilisez l'URL de style REST, vous avez la possibilité de servir un fichier statique au lieu d'exécuter du code. Dans Rails, il est courant que la première demande adressée aux étudiants / 5 crée un fichier HTML en cache sous la racine Web. Ce fichier est utilisé pour répondre aux demandes ultérieures sans toucher au backend. Naturellement, cette approche n’a rien de particulier.
L'URL ultérieure ne permettrait pas cela. Vous ne pouvez pas avoir de variables url (?, =) Dans les noms de pages statiques.
Les deux URI sont valides du point de vue de REST. Cependant, sachez que les caches Web traitent les paramètres de chaîne de requête de manière très différente.
Si vous souhaitez utiliser la mise en cache à votre avantage, je vous suggère de ne pas utiliser de paramètre de chaîne de requête pour identifier votre ressource.
Je pense que cela dépend de votre volonté de respecter les principes du feng shui.
