Niveaux d'autorisations utilisateur dans une API RESTful


23

Disons que j'ai une entreprise qui classe les chats les plus mignons sur Internet.

J'offre une ressource/cats/ qui fournit aux utilisateurs les chats adorables les plus récents et les plus mignons.

Les utilisateurs peuvent obtenir uniquement les 3 meilleurs chats s'ils n'ont pas payé du tout ou se sont inscrits. Les 10 meilleurs chats s'ils ont payé 337 dollars et sont connectés, et les 100 meilleurs chats s'ils ont payé 1337 dollars et sont connectés. J'ai un 'identifiant utilisateur' lors de la demande.

En bref, les consommateurs /cats/obtiennent un nombre différent de chats en fonction de leur «classement des utilisateurs» . J'ai un identifiant utilisateur à l'extrémité consommatrice, mais je n'ai aucune représentation explicite du niveau utilisateur à l'extrémité consommatrice. Je souhaite informer les utilisateurs qu'ils peuvent mettre à niveau leur abonnement lors de la demande. C'est-à-dire que je dois faire la distinction entre 3 chats car je n'offre que 3 chats et 3 chats parce que c'est ce que le niveau utilisateur a permis .

Quelle est la meilleure pratique pour distinguer la limitation de la ressource parce que le consommateur n'a pas les privilèges suffisants et la limiter parce que c'est ce que le consommateur a?

Comment le client sait-il s'il peut améliorer son classement? Autrement dit, ils n'ont obtenu qu'une ressource limitée car ils n'ont pas d'autorisations. Quelle est la meilleure pratique ici?

Notez qu'il s'agit d'une simplification grossière du cas réel. Aussi, juste pour clarifier - la lecture est appréciée.


Mise à jour:

Voici les options que nous avons envisagées:

  • Stockage des objets d'autorisations utilisateur une fois sur le client, recherche uniquement lorsque la connexion ou la mise à niveau du compte est effectuée.
  • Passer des nullvaleurs en JSON indiquant qu'il existe, mais rien n'a été transféré. Donc 10 chats pour un utilisateur avec 3 chats pourraient être["Garfield","Sylvester","Puss in Boots",null*7]
  • Passer une paire d'autorisations de ressources {cats:["Whiskers","Fluffy","Socks"],authCount:3}

J'aimerais bien le faire la première fois pour livrer les chats les plus mignons de la meilleure façon possible et nous aimerions et nous aimerions


4
maintenant je veux voir des photos de chats mignons
Carrie Kendall

Je ne comprends pas. Si vous ne stockez le «niveau utilisateur» nulle part, vous ne pouvez pas faire de distinction. Il semble que vous n'ayez pas non plus d'informations utilisateur stockées sur le serveur, vous ne pouvez donc pas stocker leur niveau utilisateur avec.
Jan Doggen

@JanDoggen J'ai le niveau utilisateur sur le serveur (le client transmet l'identifiant au serveur).
Benjamin Gruenbaum

Aidez-moi? Je n'ai pas la référence 1337?
Marjan Venema

Réponses:


18

Je dirais que cela dépend de votre public.

No-dev

Si votre public n'est pas un développeur, j'irais de la façon suivante:

Disons que vous renvoyez JSON pour l'exemple.

GET /cats HTTP/1.1

{
    "cats": [
        "Can I haz cheeseburger",
        "If it fits, I sits",
        "It's caturday!"
    ],
    "permissions": {
        "level": "free",
        "information": "You have access to 3 cats. Upgrade to ... to get 10 cats!"
    }
}

Ou quelque chose de similaire.

Il est informatif pour l'utilisateur de connaître le statut de son compte, et il vous permet de mettre toutes les informations que vous souhaitez, comme un message marketing. Le point le plus important de cette façon est de donner une visibilité facile à vos utilisateurs de leur compte courant.

Dev

Cependant, si votre public est purement développeur, je dirais: optez pour la méthode compatible HTTP complète. Pour stocker les métadonnées, vous utilisez des en-têtes HTTP.

Voici un exemple:

GET /cats HTTP/1.1

X-Account: anonymous
X-Account-Possible-Upgrades: 2
X-Account-Limit: 3

Ensuite, fournissez une documentation claire de la signification de ces en-têtes. La plupart des développeurs iront directement à la documentation lorsqu'ils verront ces en-têtes personnalisés, surtout s'ils voient une limite. Vous pouvez aller encore plus loin et afficher le lien dans les en-têtes. Ou vous pouvez afficher un lien vers la page de tarification.

X-Account-Doc: http://your/doc

Mais là encore, de nombreux développeurs ne savent pas comment HTTP fonctionne.

C'est donc votre appel

L'un est plus correct, l'autre est plus accessible.

Divers

Quelques autres trucs divers liés à votre question:


1
Oui, cela a un sens absolu, bien que, comme remarque, je trouve que certaines des informations d'authentification (ent / orize) contenues dans les en-têtes HTTP sont une approche appropriée car elles sont effectivement des métadonnées.
Jimmy Hoffa

@JimmyHoffa Il s'agit bien de métadonnées, et ma première pensée a été d'utiliser les en-têtes HTTP. Cependant, dans ce cas, les en-têtes HTTP n'offrent pas une visibilité suffisante au client et la granularité nécessaire pour les messages marketing. (Modifié la réponse pour ajouter ce détail.)
Florian Margaine

@JimmyHoffa comment? Un 402 ne fera pas l'affaire dans ce cas. Que suggérez-vous?
Benjamin Gruenbaum

@BenjaminGruenbaum Je n'ai pas dit de codes de réponse, j'ai dit des en-têtes; vous pouvez ajouter tous les en-têtes personnalisés que vous souhaitez pour les métadonnées, il serait sage d'avoir toutes les réponses d'une api reposante juste le rôle des utilisateurs dans l'en-tête en tant que UserRole = level1ou tout ce que vous souhaitez appeler juste pour vous assurer que les consommateurs sont toujours conscients de la façon de présenter toutes les données qu'ils reçoivent, et c'est cohérent dans toutes les réponses où les modèles de données qui reviendront seront différents d'une demande à l'autre, les consommateurs peuvent toujours vérifier leur rôle de la même manière.
Jimmy Hoffa

1
@BenjaminGruenbaum J'ai complètement réécrit la réponse.
Florian Margaine

4

Comment le client sait-il s'il peut améliorer son classement?

Cela dépend du client. Normalement, vous pouvez mettre ces informations sous la forme d'un message hypertexte (alias HTML) dans le corps de réponse de la méthode REST. Cependant, cela n'a de sens que si l'API REST est utilisée avec un client HTML.

Similaire pour XML et JSON.


Modifier: vous pourriez confondre l'utilisation d'une API (développer cet acronyme) avec la commercialisation de vos types de compte / plans d'utilisateur. Je ne mélangerais pas cela, car cela devient toujours louche (les décisions commerciales peuvent nécessiter des changements plus rapides que les changements dans le logiciel pour communiquer des réponses différentes en raison de ces changements peuvent arriver sur le plateau à temps).

Dites plutôt à vos utilisateurs via un canal différent, par exemple avec la newsletter, quels sont leurs avantages.

Cela fonctionne particulièrement bien lorsque la personne qui s'inscrit au service n'est pas celle qui programme contre l'API. Par exemple:

George (qui est un gars fièrement gay à l'âge de 36 ans qui aime les chatons) achète l'accès à cute-cats-4-me.com et dit à son conjoint de 16 ans (qui est bien avec les systèmes informatiques de script, y compris linux) de créer un application d'affichage numérique affichant de jolis petits chatons mignons sur le mur de l'appartement.

Donc, le gars qui s'amuse à programmer cela n'est pas vraiment le destinataire le plus simple de l'information.

Alternativement, en réponse à la connexion et à une méthode d'informations utilisateur, fournissez tous les détails sanglants.

Mais lorsqu'un utilisateur demande des chats par programme, il doit déjà savoir pourquoi il ne récupère que trois chats ou plus. Mais vous ne résolvez pas ce problème de communication avec du code.

Sinon, laissez-les interroger davantage, puis renvoyez un avis de défaillance si leurs droits ne sont pas suffisants. Mais encore une fois, ce n'est pas un logiciel convivial.


1
@Racheet: Avez-vous un problème lorsque les filles ont de l'argent à la maison et disent aux garçons quoi faire?
hakre

1
J'ai un problème avec un exemple qui affirme que les filles ont besoin de petits amis pour faire leur programmation pour elles.
Racheet
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.