2017-04-10 3 views
1

Référencer ce tutoriel API/explication: https://thinkster.io/tutorials/design-a-robust-json-api/getting-and-setting-user-dataPourquoi utiliser DELETE/POST au lieu de PUT pour 'ne pas suivre/suivre' un utilisateur?

Le tutoriel explique que 'suivre un utilisateur', utilisez:

POST /api/profiles/:username/follow.

Afin de 'unfollow un utilisateur', utilisez:

DELETE /api/profiles/:username/follow.

Le profil utilisateur possède initialement le champ "following": false.

Je ne comprends pas pourquoi le champ "suivant" est en cours de création/suppression (POST/DELETE) au lieu de mis à jour de true à false. J'ai l'impression de ne pas saisir ce qui se passe réellement - ne sommes-nous pas simplement en train de basculer la valeur de "suivre" entre true et false?

Merci!

Répondre

0

Je pense que la couche de base de données doit être implémentée d'une manière un peu plus complexe que de simplement avoir une colonne booléenne pour "suivre". Étant donné que vous avez trois utilisateurs, qu'est-ce que cela signifie qu'un des utilisateurs a "following": true? Est-ce que cet utilisateur suit quelque chose? Cela seul ne peut pas signifier que l'utilisateur suit tous les autres utilisateurs, non?

La couche de base de données est probablement constituée de (au moins) deux concepts différents: les utilisateurs et les suivants; les utilisateurs contiennent des informations sur l'utilisateur, et les suivants spécifient les utilisateurs qui se suivent.

dire que nous avons deux utilisateurs:

[ 
    {"username": "jake"}, 
    {"username": "jane"} 
] 

Et nous voulons dire que Jane suit Jake, mais pas l'inverse.

Ensuite, nous avons besoin de quelque chose pour représenter ce concept. Appelons que ce qui suit:

{"follower": "jane", "followee": "jake"} 

Lorsque les pourparlers de l'API sur la création ou la suppression followings, c'est probablement ce qu'ils imaginent est de se créer. C'est pourquoi ils utilisent POST/DELETE au lieu de simplement PUT. Ils ne modifient pas l'objet utilisateur, ils créent d'autres objets qui représentent les suivants.

La raison pour laquelle ils ont une partie "following": true/false dans leur réponse API JSON est parce que lorsque vous demandez des informations sur un utilisateur spécifique, comme l'un des autres utilisateurs, vous voulez savoir si vous en tant qu'utilisateur suit cet utilisateur spécifique .

Ainsi, compte tenu de l'exemple ci-dessus, lorsque jane demanderait des informations sur jake, à GET /api/profiles/jake, elle recevra quelque chose comme ceci:

{ 
    "profile": { 
    "username": "jake", 
    "bio": "...", 
    "image": "...", 
    "following": true 
    } 
} 

Cependant, quand jake demanderait les informations de profil sur les jane, il serait plutôt obtenir cette réponse:

{ 
    "profile": { 
    "username": "jane", 
    "bio": "...", 
    "image": "...", 
    "following": false 
    } 
} 

Ainsi, les informations dont ils énumèrent comme la réponse de l'API n'est pas ce qui est réellement stocké dans la base de données sur cet utilisateur spécifique, il a également Contai ns certaines informations qui sont calculées en fonction de qui a posé la question.

+1

La couche de base de données ne doit pas être pertinente pour les considérations de conception de l'API. La sémantique de POST/DELETE par rapport à PUT ne concerne que la couche API. –

+0

Je suis d'accord. Je n'utilisais que cela comme exemple, et peut-être que c'était un peu maladroit. Un "suivant" dans ce cas est un concept distinct d'un "profil d'utilisateur", et c'est bien sûr ce que l'exemple lié essaie également de nous dire. La question demande si nous ne sommes pas simplement en train de basculer une valeur booléenne. Cela m'a donné l'idée d'essayer d'expliquer une raison - pourquoi ils parlent des suivants créés/supprimés plutôt que juste pourquoi la réponse du profil serait différente avant et après une demande de suivi a été faite. – Frost

0

L'utilisation d'une microPUT serait certainement une alternative raisonnable. Je ne pense pas que quiconque puisse vous dire pourquoi un tutoriel API aléatoire a pris certaines décisions de conception. Il se peut qu'ils aient juste besoin d'un exemple artificiel pour utiliser POST/DELETE.

À moins que l'auteur ne voit cette question, je m'attends à ce que ce soit sans réponse. Il est concevable qu'ils veulent stocker des méta-informations, telles que l'horodatage du changement d'état, mais cela ne serait pas affecté par POST/DELETE vs PUT.