Concevoir / se connecter ou / enregistrer des ressources?

Question

J'ai été la conception d'une web app, puis arrêté de penser à la façon dont mon api doit être conçu comme un service web RESTful. Pour l'instant, la plupart de mes URI sont génériques et peuvent s'appliquer à diverses applications web:

GET  /logout   // destroys session and redirects to /
GET  /login    // gets the webpage that has the login form
POST /login    // authenticates credentials against database and either redirects home with a new session or redirects back to /login
GET  /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx
GET  /user/xxx // gets and renders current user data in a profile view
POST /user/xxx // updates new information about user

J'ai le sentiment que je suis en train de faire beaucoup de mal ici, après avoir farfouillé sur DONC et google.

En commençant par /logout, peut-être parce que je n'ai pas vraiment GET rien - c'est peut-être plus approprié d' POST une demande d' /logout, détruire la session, puis GET de la redirection. Et si l' /logout durée du séjour?

Qu'en /login et /register. Je pourrais changer de /register de /registration mais qui n'altère pas comment mon service fonctionne - s'il a des questions plus profondes.

Je remarque maintenant que je n'exposez jamais une /user des ressources. Cela pourrait peut-être être utilisé en quelque sorte. Par exemple, l'utilisateur myUser:

foo.com/user/myUser

ou

foo.com/user

L'utilisateur final n'a pas besoin de ce surplus de verbosité dans l'URI. Cependant, ce qui est le plus attrayant visuellement?

J'ai remarqué que certains d'autres questions sur ce sujet RESTE d'entreprise, mais je voudrais vraiment l'apprécier quelques conseils sur ce que j'ai écrit ici si possible.

Merci!

Mise à JOUR:

Je voudrais aussi quelques avis sur:

/user/1

vs

/user/myUserName

Answer 1

Reposant peut être utilisé comme un guide pour la construction des Url, et vous pouvez faire des sessions et utilisateurs de ressources:

• GET /session/new obtient la page web qui a le formulaire de connexion
• POST /session authentifie les informations d'identification à l'encontre de la base de données
• DELETE /session détruit la session et de les rediriger vers /
• GET /users/new obtient la page web qui a le formulaire d'inscription
• POST /users enregistre les informations saisies dans la base de données en tant que nouveau /utilisateur/xxx
• GET /users/xxx // reçoit et rend l'utilisateur actuel des données dans une vue de profil
• POST /users/xxx // les mises à jour de nouvelles informations sur l'utilisateur

Ceux-ci peuvent être au pluriel ou du singulier (je ne sais pas laquelle est la bonne). Habituellement, j'ai utilisé /users pour un utilisateur de la page d'index (comme prévu), et /sessions pour voir qui est connecté (comme prévu).

Utiliser le nom dans l'URL au lieu d'un nombre (/users/43 vs /users/joe) est généralement motivés par le désir d'être plus convivial pour les utilisateurs ou les moteurs de recherche, pas toutes les exigences techniques. Soit est très bien, mais je vous recommande de sont cohérentes.

Je pense que si vous allez avec le s'inscrire/connexion/déconnexion ou sign(in|up|out), il ne fonctionne pas aussi bien avec le repos de la terminologie.

Answer 2

Les séances ne sont pas Reposantes

• Oui, je sais. Cela se fait, généralement avec OAuth, mais vraiment sessions ne sont pas de tout repos. Vous ne devriez pas avoir un /connexion /déconnexion des ressources principalement parce que vous ne devriez pas avoir de sessions.

• Si vous allez le faire, le faire de tout repos. Les ressources sont des noms et /login et /déconnexion ne sont pas des noms. Je voudrais aller avec /session. Cela rend la création et la suppression d'un plus naturel de l'action.

• POST vs REÇOIS pour des séances est facile. Si vous êtes l'envoi d'utilisateur/mot de passe que pour les variables, je voudrais utiliser POST, parce que je ne veux pas avoir le mot de passe est envoyé en tant que partie de l'URI. Elle va apparaître dans les journaux et, éventuellement, être exposés sur le fil. Vous courez également le risque d'avoir un logiciel échouer sur OBTENIR args limites.

• Je l'utilise généralement l'Authentification Basique ou pas d'Auth avec le RESTE des services.

La création d'utilisateurs

• C'est l'une des ressources, de sorte que vous ne devriez pas /vous inscrire.

  • POST /l'utilisateur Crée un utilisateur si le demandeur ne peut pas spécifier l'id
  • METTRE /utilisateur/xxx - Créer ou mettre à jour un utilisateur en supposant que vous connaissez l'id d'avance
  • GET /l'utilisateur des listes de x id utilisateur
  • GET /utilisateur/xxx - Obtient les détails de l'utilisateur avec l'id xxx
  • SUPPRIMER /utilisateur/xxx - Supprimer l'utilisateur avec l'id xxx

• Le type de l'ID à utiliser est une question difficile. Vous devez penser au sujet de l'application de l'unicité, sur la réutilisation de vieux identifiants qui ont été Supprimés. Par exemple, vous ne voulez pas utiliser ces identifiants comme des clés étrangères sur un backend si les identifiants sont va être recyclés (si possible). Vous pouvez avoir une liste de choix, bien que pour les externes/internes id de conversion afin d'atténuer backend exigences.

Answer 3

Une chose ressort en particulier de ne pas REST-ful: l'utilisation d'une requête GET pour vous déconnecter.

(à partir de http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods)

Certaines méthodes (par exemple, de la TÊTE, d'OBTENIR, d'OPTIONS et de TRACE) sont définies comme "sûrs", ce qui signifie qu'ils sont destinés uniquement pour la recherche d'information et ne devraient pas changer l'état du serveur. En d'autres termes, ils ne devraient pas avoir d'effets secondaires, au-delà relativement inoffensif des effets tels que l'exploitation forestière, la mise en cache, le service de bannières publicitaires ou d'incrémenter un compteur. [...]

[... H]andling [des requêtes GET] par le serveur n'est pas techniquement limité en aucune façon. Par conséquent, négligents ou délibérée de la programmation peut entraîner la non-trivial modifications sur le serveur. Cela est déconseillé, car il peut causer des problèmes pour la mise en cache Web, les moteurs de recherche et autres automatisé des agents de [...]

Comme pour l'enregistrement et redirection, vous pourriez avoir un post à votre déconnexion URI donner un 303 réponse de la rediriger vers le post-page de déconnexion.

http://en.wikipedia.org/wiki/Post/Redirect/Get

http://en.wikipedia.org/wiki/HTTP_303

Modifier à l'adresse URL problèmes de conception:

"Comment concevoir mes ressources?" est une question importante pour moi: "comment puis-je concevoir mon Url?" est prise en considération dans deux domaines:

Les url que l'utilisateur voit ne devrait pas être trop moche et de sens que si possible; si vous voulez des cookies pour être envoyé dans les demandes de certaines ressources, mais pas d'autres, vous aurez envie de structure de vos sentiers et chemins du cookie.

Si JRandomUser veut regarder son propre profil et que vous voulez l'URL pour être plus jolie que foo.com/user/JRandomUser ou foo.com/user/(JRandom's numeric user id here), vous pourriez faire une URL distincte juste pour un utilisateur de regarder leurs propres informations:

GET foo.com/profile /*examines cookies to figure out who 
                     * is logged in (SomeUser) and then 
                     * displays the same response as a
                     * GET to foo.com/users/SomeUser.
                     */

Je voudrais demander l'ignorance beaucoup plus facilement que la sagesse sur ce sujet, mais voici quelques ressources considérations de conception:

1. Consommation: quelles ressources sont destinées à être vues directement dans un navigateur, charger via XHR, ou accessible par un autre type de client?
2. Accès / identité: la réponse dépendent des cookies ou des référents?

Answer 4

Je vais simplement parler de mon expérience dans l'intégration de divers Services Web REST pour mes clients, si elle est utilisée pour les applications mobiles ou pour un serveur à l'autre de la communication, ainsi que la construction de l'API REST pour les autres. Voici quelques observations que j'ai recueillies auprès d'autres personnes API REST ainsi que ceux que nous avons construit nous-mêmes:

• Quand nous disons de l'API, il se réfère normalement à l'ensemble de la programmation de l'interface et pas nécessaire de la couche de présentation. Le REPOS est également centré sur les données et non pas de présentation conduit. Qui a dit que la plupart de REPOS renvoyer des données sous la forme de JSON ou XML et rarement de retour d'une présentation spécifique de la couche. Ce trait de caractère (de retour de données et non pas directement de la page web) a donné le REPOS capacité de faire de la multi-canaux de la livraison. Ce qui signifie que le même service peut être rendu en HTML, iOS, Android ou même être utilisés comme un serveur à l'autre combinaison.
• Il est très rare de combiner à la fois HTML et le RESTE sous forme d'une URL. Par défaut, les autres sont pensées comme des services et de ne pas avoir de couche de présentation. C'est le travail pour ceux qui consomment le webservices afin de rendre les données et les services qu'ils appellent en fonction de ce qu'ils veulent. À ce point de votre URL ci-dessous n'est pas conforme avec la plupart de REPOS en fonction de la conception que j'ai rencontré jusqu'à présent, ni les normes telles que celles qui sont à venir à partir de Facebook ou Twitter)

OBTENIR /enregistrer // obtient la page web qui a le formulaire d'inscription

• Continuer à partir du point précédent, il est également rare (et je n'ai pas rencontré) pour RESTE à faire la redirection, telles que celles suggérées ci-dessous:

OBTENIR /déconnexion // détruit la session et redirige vers /
POST /login // authentifie les informations d'identification à l'encontre de la base de données et soit redirige à la maison avec une nouvelle session ou la renvoie à /login
 

Que le REPOS sont conçus comme des services, des fonctions telles que la connexion et la déconnexion sont normalement de retour de réussite ou d'échec résultat (normalement en JSON ou XML format de données) qui est le consommateur de l'interpréter. Une telle interprétation pourrait inclure la redirection de page web appropriée comme vous l'avez mentionné

• Au RESTE, l'URL signifier les actions qui sont prises. Pour cette raison, nous devrions enlever comme beaucoup d'ambiguïté possible. S'il est légitime, dans votre cas, d'avoir à la fois GET et POST qui a le même chemin d'accès (comme /enregistrer) d'effectuer différentes actions, telles la conception d'introduire de l'ambiguïté dans les services fournis et peuvent dérouter le consommateur de vos services. Par exemple, l'Url comme celle que vous présentez ci-dessous ne sont pas idéales pour le REPOS des services basés sur l'

OBTENIR /enregistrer // obtient la page web qui a le formulaire d'inscription
POST /register // enregistre les informations saisies dans la base de données en tant que nouveau /utilisateur/xxx

Ce sont quelques points de ce que j'ai traités. J'espère qu'elle pourra fournir quelques informations pour vous.

Maintenant que la mesure de mise en œuvre de votre REPOS, ces sont typiques de la mise en œuvre que j'ai rencontré:

• OBTENIR /déconnexion 
  

  Exécuter déconnexion dans le backend et le retour JSON pour la dénotation de la réussite/l'échec de l'opération

• POST /login
  

  Envoyer des informations d'identification à l'arrière-plan. De retour de réussite ou d'échec. En cas de succès, normalement, il devrait aussi retourner le jeton de session ainsi que les informations de profil.

• POST /enregistrer
  

  Soumettre l'enregistrement en arrière-plan. De retour de réussite ou d'échec. En cas de succès, normalement traités de la même façon que la connexion réussie, ou vous pourriez choisir de faire de l'enregistrement en tant que service distinct

• GET /utilisateur/xxx
  

  Obtenir le profil utilisateur et le retour JSON format de données pour le profil de l'utilisateur

• POST /utilisateur/xxx 
  // renommé 
  POST /updateUser/xxx
  

  Post mis à jour les informations de profil que le format JSON et mettre à jour les informations dans le backend. De retour de réussite ou d'échec à l'appelant

Answer 5

L'utilisation et la conception d'API ne concernent pas uniquement les URL visuellement attrayantes , mais les URL qui ont du sens. Pour l'enregistrement / la connexion des utilisateurs, j'ai déjà utilisé ceux-ci:

 GET  /user          // Get multiple user info (limit ~10)
GET  /user/1        // Get single user info
POST /user          // Create user (registration)
PUT  /user/1        // Edit user
POST /user/1/login  // Login (could be GET, but I like sending more secure params by POST)
GET  /user/1/logout // Logout