Je suis un peu en retard à la fête, mais j'essaie de comprendre comment REST est censé fonctionner, à la fois en général et dans Ruby on Rails. J'ai déjà lu un tas d'articles en ligne à ce sujet, mais je n'ai toujours pas l'impression d'avoir une vue d'ensemble. REST si je comprends bien, est une série de déclarations aspirationnelles, avec le résultat net au fond étant que les URL doivent contenir toutes les informations nécessaires pour traiter une demande, et ne doit pas être en mesure de changer l'état sur le serveur, et un tas d'autres directives concrètes. Si je comprends bien, REST in Rails est basé sur CRUD, c'est-à-dire que chaque modèle a une action create, read, update et delete. Chacune de ces actions est accessible via un ensemble d'URL similaire, généré en mappant une ressource dans les routes. Ainsi, une URL de connexion crée une session utilisateur, l'URL ressemblerait à example.com/session/new avec un POST, et la déconnexion serait example.com/session/destroy avec un POST.Comprendre REST conceptuellement avec Rails
Quel est l'avantage de normaliser les URL de cette façon? Cela me semble optimaliser la lisibilité de la machine au détriment de la lisibilité humaine. Je sais que vous pourriez alors remapper dans le fichier de routes example.com/login à example.com/session/new mais c'est juste un pas de plus pour aucun gain apparent pour moi.
Est-ce vraiment une mauvaise pratique de développer un site Web qui utilise maintenant des itinéraires traditionnels?
De plus, chacune de ces actions CRUD devrait être capable de répondre aux demandes avec n'importe quel type de réponse que la requête recherche. Ainsi, le même lien vers example.com/tasks peut également être appelé sur example.com/tasks.xml pour obtenir une représentation xml du résultat, ou sur example.com/tasks.json pour une représentation json. Est-ce pour dire qu'une API RESTful serait simplement les liens habituels sur le site mais avec XML ajouté? Il me semble très étrange et gênant qu'une API Web se comporte de cette manière, mais cela semble être ce qui est impliqué par tout ce que j'ai lu. Je suis plus habitué à voir une API qui a des liens comme example.com/api/tasks pour obtenir la liste des tâches. Quel est exactement l'avantage de cette approche?
"Au détriment de la lisibilité humaine"? Je dirais le contraire, s'en tenir à un schéma d'URL spécifique pour tout ce qui rend simple à comprendre et à travailler avec. – deceze
Mais il existe déjà un schéma d'URL pour les humains normaux (pas les développeurs). Ce schéma que tous les utilisateurs du Web sont déjà à l'aise dit example.com/login est l'endroit où vous allez vous connecter, pas example.com/session/new. Donc, pour quelque chose comme la connexion, quel est l'avantage de passer au système d'URL REST? Juste pour alléger le fardeau sur les développeurs à comprendre et à travailler avec? Je ne vois pas comment cela améliore la lisibilité de l'utilisateur final. –
Tout le concept de connexion est sans doute plutôt RESTless, car il introduit le concept d'état. Je ne pense pas que RESTfulness prescrive des schémas d'URL d'une manière si spécifique, '/ login' est toujours une URL parfaitement bonne * si cela correspond à votre objectif *. Je voulais dire * en général *, coller à un schéma spécifique est * bon * pour la lisibilité humaine. Comme vous le dites, '/ login' est déjà un schéma accepté, donc c'est bon. – deceze