L'état de lecture fait-il partie intégrante de la ressource ou s'agit-il simplement d'une fonction de suivi côté serveur? Les lecteurs voudraient-ils obtenir des listes de tous les documents qui sont «lus» ou «non lus»? Les utilisateurs pourront-ils marquer un document comme "non lu" s'ils le téléchargent mais décider de le lire plus tard?
Si c'est juste côté serveur, alors il est bon de marquer un tuple {user,resource} comme lu sur chaque requête GET. Si l'état de lecture par utilisateur fait partie de la ressource, vous avez besoin d'un mappage plusieurs-à-plusieurs client-inscriptible entre les utilisateurs et les ressources, et la paire est mappée (en lecture) ou non (non lue). Dans ce cas, je suggère d'utiliser une nouvelle ressource pour représenter ce statut, et permettre au client de METTRE un vrai/false booléen à cet URI de ressource. Que ce soit [email protected]/resource/read ou /user/{user}/resource/read ou un autre, cela n'a pas vraiment d'importance. Si vous voulez que ce drapeau soit défini automatiquement et que votre client soit un navigateur Web, vous devrez utiliser AJAX pour faire une deuxième requête une fois le document téléchargé (et peut-être que l'onglet a été visible pour un temps écoulé). période).
Que diriez-vous d'un POST, je veux dire, combien de types de demande sont là. – Arvin
@Arvin POST semble juste comme le mauvais verbe à moi, comme la fonction principale est de récupérer la page, avec le marquage comme étant un effet secondaire. Je suppose que POST est la voie à suivre, je pensais juste que quelqu'un pourrait avoir une situation plus élégante. – tsvallender
Si les entités que vous générez possèdent un attribut qui indique si elles ont été lues ou non, je recommanderais d'utiliser un PUT sinon je ne m'inquiéterais pas de les marquer comme lues dans le GET. – abraham