J'essaie de savoir si FeathersJS répond à mes besoins. J'ai examiné plusieurs exemples et cas d'utilisation. FeathersJS utilise un ensemble de méthodes de requête: find , get , create , update , patch et supprimer . Aucune autre méthode et encore moins les méthodes personnalisées ne peuvent être implémentées et utilisées, comme confirmé sur cet autre message SO. .
Imaginons cette application où les utilisateurs peuvent enregistrer leurs paramètres d'application. Sans tenir compte des conventions de méthode suivantes, je créerais un point de terminaison décrivant l'action effectuée par l'utilisateur. Dans ce cas, nous pourrions avoir, par exemple: / saveSettings . Sachant qu'il n'y aura pas de paramétrage - recherche , - création , - mise à jour (seulement quelques - correctifs ) ou - suppression . Je pourrais aussi avoir besoin d'une route / getSettings .
Ma question est la suivante: chaque action peut-elle être réduite à ces méthodes de requête? Pour moi, ces actions sont fortement liées à une collection / modèle spécifique. Parfois, nous devons créer des actions qui ne sont pas liées à une seule collection et qui pourraient potentiellement interagir avec plus d'une collection / modèle.
Pour cet exemple, je suppose qu'il serait traduit en FeathersJS avec un service nommé Setting qui contiendrait deux méthodes: get () et un patch () .
Si c'est la bonne approche, il me semble que cette solution est plus orientée serveur que orientée client dans le sens que nous devons savoir, côté client, quelle collection sous-jacente va être modifiée ou affectée. On a l'impression que nous perdons un certain niveau de liberté en n'ayant pas une sorte de routage entre les points de terminaison et les services (comme nous l'avons dans vanilla ExpressJS).
Voici un autre exemple: j'ai un personnage de jeu qui peut améliorer ses compétences. Lorsque l'utilisateur décide de renforcer une compétence particulière, une demande est envoyée au serveur. Ce point de terminaison peut ressembler à POST: / skillUp Que serait-il dans FeathersJS? en implémentant SkillUpService # create?
J'espère que vous rencontrez le problème que j'essaie de souligner ici. Avez-vous des idées à partager ou des recommandations sur la manière d'organiser l'API dans ce cadre particulier?
3 Réponses :
Je ne suis pas un expert des featherJs, mais si vous construisez votre base de données et vos modèles avec une bonne logique, ces méthodes sont tout ce dont vous avez besoin:
pour l'exemple de paramétrage, saveSettings correspond à setting.patch ({options}) donc à l'itinéraire settings /: id? options (méthode PATCH) car l'utilisateur a déjà des paramètres par défaut (créés avec l'utilisateur). getSetting correspondrait à setting.find(query)
Pour créer l'utilisateur ET les paramètres, je suppose que vous avez une méthode pour appeler setting.create ({defaultOptions}) lorsque l'utilisateur CREATE route est appelé. Ce serait la bonne manière.
pour la route skillUp , dépend de la conception de votre base de données, mais je suppose que ce serait quelque chose comme une table qui vous donne le niveau / les compétences / le caractère, vous avez donc besoin d'un service pour cela table spécifique et pour appeler skillLevel.patch ({character, level})
Merci d'avoir pris le temps de répondre. C'est une toute nouvelle façon pour moi d'organiser l'API et il y a certainement beaucoup à penser. Ce qui m'a dérangé au début, ce sont les contraintes fixées par FeathersJS à la fois sur les itinéraires et sur les méthodes de requête disponibles.
En plus de la bonne réponse que @ gui3 a déjà donnée, il vaut probablement la peine de souligner que Feathers est intentionnellement restreint afin de vous aider à créer RESTful API qui se concentrent sur les ressources (données) et un ensemble connu de méthodes que vous pouvez exécuter sur celles-ci.
Outre la réponse que vous avez liée, cela est également expliqué plus en détail dans la FAQ et une introduction à la conception de l'API REST et pourquoi Feathers fait ce qu'il fait peut être trouvée dans cet article: Modèles de conception pour les API Web modernes . Ce sont les meilleures pratiques qui ont aidé à adapter Internet (en particulier le protocole HTTP) à ce qu'il est aujourd'hui et qui peuvent très bien fonctionner pour créer des API. Si vous souhaitez toujours utiliser les itinéraires que vous suggérez (ce qui n'est pas RESTful), alors Feathers n'est pas le bon outil pour le travail.
Merci pour votre réponse. Je n'ai pas trouvé cette page de FAQ en lisant les documents. C'est très instructif de voir une API construite de cette façon. Après avoir regardé la vidéo, j'ai une question qui semble liée: à 19:20 vous afficher deux méthodes côté client appelant submitService # patch avec deux paramètres différents, qu'entendez-vous par "vous feriez cela avec des crochets sur le serveur" ?.
Une stratégie que vous voudrez peut-être envisager consiste à utiliser un paramètre de requête dans un corps POST tel que {"action": "type"} et utilisez une instruction switch pour effectuer conditionnellement l'action souhaitée. Un exemple de cette stratégie est présenté dans ce tutoriel . < / p>