Disons que j'ai un service reposant et hypertexte qui modélise un magasin de crème glacée. Pour aider à mieux gérer mon magasin, je souhaite pouvoir afficher une quantité quotidienne de rapport et une valeur dollar de chaque type de crème glacée vendue.
Il semble que cette capacité de déclaration puisse être exposée comme une ressource appelée DailyRePort. Un DailyRePort peut être généré rapidement et il ne semble pas y avoir d'avantage de stocker des rapports sur le serveur. Je veux seulement un DailyReport depuis quelques jours, d'autres jours, je me fiche de recevoir un DailyRePort. De plus, stocker des dailyreports sur le serveur compliquerait les implémentations des clients, ce qui nécessiterait N'oubliez pas de supprimer des rapports dont ils n'ont plus besoin.
Un DailyReport est transitoire; Sa représentation ne peut être récupérée qu'une seule fois. Un moyen de mettre en œuvre ce serait d'offrir un lien "/ rapports quotidiens", un post auquel retournera une réponse contenant une représentation de DailyRePort inscrivant les informations pour les ventes de cette journée.
éditer: disons aussi que je veux vraiment faire une demande postale. Un DailyReport a de nombreuses options différentes pour créer une vue, telle que le tri des types de crèmes glacées par ordre alphabétique, par une valeur de dollar - ou avec une ventilation horaire - ou éventuellement incluant la température de ce jour - ou filtrant certains types de crème glacée (en tant que liste). Plutôt que d'utiliser des paramètres de requête avec un get, je préférerais afficher une représentation DailyRePort avec les options appropriées (à l'aide d'un type de support personnalisé bien défini pour documenter chaque option). La représentation que je récupère afficherait mes options avec le rapport lui-même.
Est-ce la bonne façon de penser au problème, ou si une autre approche doit-elle être utilisée à la place? Si vous êtes correct, quelles considérations spéciales pourraient être importantes lors de la mise en œuvre de la ressource DailyReRePort? (Par exemple, il ne serait probablement pas approprié de définir l'en-tête de localisation lors de son retour après une demande postale).
4 Réponses :
Il n'est pas nécessaire d'utiliser un poste pour cela, car demandez le rapport ne modifie pas l'état du serveur. J'utiliserais une ressource comme celle-ci: répondant à votre édition: Si vous publiez une description du rapport à une URL et récupérez une définition de données temporaires en conséquence, Ce n'est pas du tout reposer. C'est RPC, dans la même veine que le savon. RPC n'est pas une chose intrinsèquement mauvaise, mais s'il vous plaît, n'allez pas l'appeler reposant.
Bon point. Et s'il y avait plusieurs paramètres pouvant être appliqués au DailyRePort - par exemple, trier des types de crème glacée alphabétiquement ou par chiffre dollar - et si je ne voulais pas utiliser les paramètres de requête pour le faire? Ou si je voulais activer la plage de date à définir sur autre chose que les 24 dernières heures, c'est-à-dire une ressource de rapport plus générale? Disons que je ne veux pas inclure ces options en tant que paramètres de requête, mais plutôt comme une représentation à part entière envoyée en tant que courrier postal? C'est plus proche de ce que je pense.
Pourquoi ne voulez-vous pas utiliser les paramètres de requête? C'est ce qu'ils existent pour. Des plages de rapport personnalisées peuvent également être fournies avec des paramètres de requête. Si les paramètres sont si complexes qu'ils ne peuvent pas être représentés dans la chaîne de requête, il peut être utile de les télécharger sur le serveur et de rendre le rapport quotidien une sous-ressource.
Si vous souhaitez effectuer des rapports quotidiens depuis des jours passés disponibles, vous pouvez l'implémenter comme un accès à L'avantage de rendre le rapport pour chaque jour disponible car sa propre URI est la cache-câble.
EDIT: Une bonne solution peut être de fusionner les deux réponses, rendant / Daily_Reports / 2009/08/20 . Je suis d'accord avec John Millikin qu'un poste est inutile ici - il n'y a pas besoin de quelque chose comme celui-ci pour être une ressource créatrice de l'utilisateur.
quotidien_report / une représentation sans cache des données de la journée et Daily_Reports / aaaa / mm / dd une représentation macérable des données d'une journée complète.
Récemment fait quelque chose comme ça, sauf que j'ai (jusqu'à présent) faite quotidien_report une redirection non permanente à la version permanente.
Je pense L'approche de Greg est la bonne. Pour exposer sur elle, je ne pense pas que vous devriez fournir une ressource / rapport quotidien qui change quotidiennement, car l'exécution du rapport mardi à 11h59 produirait des résultats différents que le fonctionnement mercredi à 00 : 01, qui peut être a) déroutant pour les clients s'attendant à ce que la ressource soit la même, et b) ne permettent pas aux clients de récupérer les données de la journée précédente après la réception de la journée. Vous devez fournir un identifiant de ressource unique pour chaque rapport quotidien disponible, ainsi que des clients peuvent accéder aux informations dont elles ont besoin à tout moment.
Il est assez courant d'avoir un type de ressource de / aujourd'hui. Un client ne doit pas être surpris lorsqu'une ressource change entre GET.
Je suis d'accord avec le commentaire de Darrel, il suffit d'ajouter l'en-tête expiré approprié. Il est parfaitement valable pour obtenir une ressource qui représente quelque chose de courant au moment où il a été récupéré. Si vous souhaitez rendre plus claire au consommateur d'API, vous voudrez peut-être avoir des formats d'URI séparés: / Signaler quotidien / Archives / Daily-Rapports / 2009/02/12 Je suis sûr que quelqu'un va sauter et mentionner le repos Soin de la conception de l'URI, mais ils sont importants pour concevoir une API utilisable.
Parfois, il est souhaitable de conserver un enregistrement de demandes de rapports, dans ces cas, il n'est pas déraisonnable de poster à une ressource de collecte. Il est également utile pour les rapports de longue date où vous voulez gérer l'exécution de manière asynchrone. Combien de temps le serveur détient sur ces demandes de rapport est à vous.
Je ferais quelque chose comme qui retournerait une représentation de la demande, y compris des options et Lorsque le rapport est terminé, un lien vers les résultats du rapport. Une autre alternative qui est bonne lorsque vous avez un ensemble de rapports pré-conserves consiste à créer une ressource DailyRePorts contenant une liste de liens de rapport préconfigurés. Le openSearchDescription SPEC vous permet de faire quelque chose de similaire à celui-ci à l'aide de la balise de requête.