Type de média de repos explosion

Question

Dans ma tentative de refonte d'une application existante à l'aide de style architectural REST, je suis tombé sur un problème que je voudrais à terme comme "Mediatype Explosion". Cependant, je ne suis pas sûr si c'est vraiment un problème ou un avantages inhérents de REPOS. Pour expliquer ce que je veux dire, prenons l'exemple suivant

Une petite partie de notre application ressemble à:

collection-des-collections->collections-des-articles->items

j'.e haut niveau est une collection de collections et chacun de ces la collection est à nouveau une collection d'éléments.

Aussi, chaque élément a 8 attributs qui peuvent être lues et écrites individuellement. Essayer d'exposer la au-dessus de la hiérarchie de repos ressources me laisse avec la des types de média suivants:

application/vnd.mycompany.collection-of-collections+xml
application/vnd.mycompany.collection-of-items+xml
application/vnd.mycompany.item+xml

De plus, étant donné que chaque élément a 8 attributs qui peuvent être lues et écrites individuellement, il en résultera un autre de 8 types de médias. par exemple, un tel type de support pour l'attribut "value" d'un élément serait:

application/vnd.mycompany.item_value+xml

Comme je l'ai mentionné plus tôt, ce n'est qu'une infime partie de notre application et j'attends plusieurs différentes collections et des éléments qui doit être exposée de cette façon.

Mes questions sont les suivantes:

1. Suis-je en train de faire quelque chose de mal par rapport à ce grand nombre de types de médias?
2. Qu'est-ce que la conception alternative de la méthode pour éviter cette explosion de types de médias?

Je suis également conscient que le design est très granulaire, en particulier d'exposer les attributs de l'élément et à la séparation des types de médias pour chacun d'eux. Toutefois, il grossière signifie que je vais finir le transfert de données inutiles sur le fil alors qu'en réalité, il suffit au client de lire ou d'écrire un seul attribut d'un élément. Comment voulez-vous aborder un tel problème de conception?

Answer 1

Une approche qui permettrait de réduire le nombre de types de médias est nécessaire d'utiliser un type de support défini à tenir des listes d'autres types de médias. Cela pourrait être utilisé pour toutes vos collections. Généralement, les listes ont tendance à avoir un ensemble cohérent de comportement. Vous pourriez rouler vos propres vnd.mycompany.resourcelist ou vous pourriez réutiliser quelque chose comme un Atome de collection.

En ce qui concerne la ressource spécifique de représentations comme vnd.mycompany.item, ce que vous pouvez faire dépend beaucoup des caractéristiques de votre client. Est-il dans un navigateur? pouvez-vous faire de code de téléchargement? Est votre client, une INTERFACE utilisateur riche, ou est-il un traitement de données client?

Si le client va faire spécifiques de traitement de données, puis vous devez coller avec précision les types de médias et vous pouvez vous retrouver avec un grand nombre d'entre eux. Mais regardez le bon côté des choses, vous aurez moins de types de médias que vous auriez des espaces de noms si vous utilisez du SAVON!

Rappelez-vous, les médias-type est de votre contrat, si votre application a besoin de définir beaucoup de contrats avec le client, alors ainsi soit-il.

Cependant, je n'irais pas aussi loin que la définition des contrats d'échange unique des valeurs d'attribut. Si vous vous sentez le besoin de le faire, alors vous faites quelque chose de mal dans votre conception. Distribué design de l'interface a besoin d'avoir de gros morceaux de conversations, pas bavard ceux.

Answer 2

Je pense que j'ai finalement obtenu la clarification j'ai cherché pour la question ci-dessus à partir de Ian Robinson présentation et pensé que je devrais la partager ici.

Récemment, je suis tombé sur la déclaration de "type de support pour aider à régler le hypermédia moteur, schéma de structure" dans une entrée de blog par Jim Webber. J'ai ensuite trouvé cette présentation par Ian Robinson de Thoughtworks. Cette présentation est l'un des meilleurs que j'ai rencontré qui fournit une très bonne compréhension des rôles et des responsabilités de types de médias et de langages de schéma (l'ensemble de la présentation est un régal et je le recommande fortement pour tous). Surtout affût pour les diapositives intitulé "Vous avez Choisi d'application/xml, vous b* * * * st*rd." et "Custom types de médias". Ian explique clairement les différents rôles des schémas et les types de médias. En bref, c'est mon point de vue est loin de Ian présentation:

Un type de support description comprend le modèle de traitement qui identifie l'hypermédia contrôle et définit les méthodes sont applicables pour les ressources de ce type. L'identification de l'hypermédia contrôles "Comment pouvons-nous identifier des liens?" en XHTML, les liens sont identifiés sur la base de la balise RDF et ont des sémantiques différentes pour la même chose. La prochaine chose que de types de médias aider à identifier quelles sont les méthodes applicables pour les ressources d'un type de média? Un bon exemple est l'ATOME (application/atom+xml) spécification qui donne une très riche description de l'hyper media contrôles; ils nous disent comment le lien de l'élément est définie? et ce que nous pouvons nous attendre à être en mesure de le faire lorsque nous déréférencer un URI si elle a effectivement dit quelque chose sur les méthodes que nous pouvons nous attendre à être en mesure de s'appliquer à la ressource. L'information structurelle d'une ressource represenation est PAS partie ou ne PAS contenue dans le type de support description, mais elle est assurée dans le cadre du schéma appropriées de la représentation réelle de la je.e le type de support de la spécification n'est pas nécessairement dicter quoi que ce soit à propos de la structure de la représentation.

Alors qu'est-ce que cela signifie pour nous? tout simplement que nous n'avons pas besoin d'un autre type de support pour la description de chaque ressource comme décrit ci-dessus dans ma question initiale. Nous avons juste besoin d'un type de support pour l'ensemble de l'application. Cela pourrait être un tout nouveau custom type de support ou un support personnalisé de type qui réutilise norme existante types de médias ou, mieux encore, il suffit d'un standard type de support qui peuvent être réutilisés sans changement dans notre application.

Espérons que cette aide.

Answer 3

À mon avis, c'est le maillon faible du RESTE de concept. Comme l'architecture et le style de l'interface, le REPOS est la circulation et le travail fait par le Roy F. et d'autres ont avancé l'état de l'art considérablement. Mais il existe une limite supérieure à ce qui peut être communiqué (et pas seulement représenté) par la norme les types de médias.

Pour les personnes à comprendre et à utiliser votre REPOS-ish API, ils ont besoin de comprendre la signification des données. Il y a des Api où les types de supports dire la plupart de l'histoire; par exemple, si vous avez un text-to-speech API, le support d'entrée est de type text/plain et la sortie type de média (audio / mp4, puis quelqu'un de familier avec le sujet pourrait probablement faire. Texte, audio, probablement assez pour aller dans ce cas.

Mais de nombreuses Api ne peut pas communiquer beaucoup de leur sens avec juste le type de média. Disons que vous avez une API qui gère de la compagnie aérienne de la billetterie. Les entrées et les sorties seront pour la plupart des données. Les types de médias sur l'entrée et la sortie de chaque API pourrait être d'application/json ou de l'application/xml, de sorte que le type de média n'est pas de transmettre beaucoup d'informations. Alors vous regardez les différents champs des entrées et sorties. Peut-être il ya un champ appelé "prix". C'est qu'en dollars ou en pièces d'un cent? USD ou en une autre devise? Je ne sais pas comment l'utilisateur de répondre à ces questions sans que ce soit (un) très descriptives des noms, comme "price_pennies_in_usd", ou (b) de la documentation. Pour ne pas mentionner le format de conventions. Est un numéro de compte fourni avec ou sans tirets, doivent être des lettres majuscules, et ainsi de suite. Il n'y a pas de norme type de média qui définit ces questions.

C'est une chose, lorsque nous sommes dans des situations où le client n'a pas besoin d'une sémantique de la compréhension des données. Qui fonctionne bien. Le fait que les navigateurs peuvent visuellement le rendu de tout document conforme à l', et d'interagir avec toutes les ressources conforme à la norme, est vraiment génial. C'est en gros les "médias" cas d'utilisation.

Mais il est tout à fait autre chose, quand le client (ou en fait, le développeur/utilisateur derrière le client) doit comprendre la sémantique des données. LES DONNÉES NE SONT PAS LES MÉDIAS. Il n'y a aucune façon d'expliquer les données dans le monde réel sens et la subtilité autre que le documenter. C'est le "cas d'utilisation".

Le trop-définition académique de REPOS, fonctionne bien dans les médias de cas d'utilisation. Il n'a pas de travail, et doit être complétée par des non-pur, mais des choses utiles comme la documentation, pour les autres cas.

Answer 4

Vous utilisez le type de média pour transmettre les détails de vos données qui doivent être stockées dans la représentation elle-même. De sorte que vous pouvez avoir un seul type de média, dire "application/xml", et puis vos représentations XML ressemblerait à:

<collection-of-collections>
    <collection-of-items>
        <item>
        </item>
        <item>
        </item>
    </collection-of-items>
    <collection-of-items>
        <item>
        </item>
        <item>
        </item>
    </collection-of-items>
</collection-of-collections>

Si vous êtes préoccupé par l'envoi de trop de données, substitut du JSON en XML. Une autre façon d'économiser sur les octets écrit et la lecture est d'utiliser l'encodage gzip, ce qui réduit les choses à environ 60-70%. Sauf si vous avez à ultra-haute performance des besoins, l'une de ces approches devraient bien fonctionner pour vous. (Pour de meilleures performances, vous pouvez utiliser très laconique, fabriqués à la main des cordes, ou même déplacer vers le bas pour un binaire protocole TCP/IP.)

Modifier l'Une de vos préoccupations est que:

faire [représentation] grossier signifie que je vais finir le transfert de données inutiles sur le fil alors qu'en réalité, il suffit au client de lire ou d'écrire un seul attribut d'un élément

Dans n'importe quel service web il y a beaucoup de frais généraux dans l'envoi de messages (chaque requête HTTP peut coûter plusieurs centaines d'octets de la ligne de départ et les en-têtes de requête et idem pour chaque réponse HTTP, comme dans cet exemple). Donc, en général, vous voulez avoir moins précis représentations. Si vous écrivez votre client de demander ces grandes représentations et ensuite de les mettre en cache dans certains commode structure de données en mémoire l'endroit où votre programme peut lire des données à partir de nombreuses fois (mais assurez-vous de l'honneur de la HTTP date d'expiration de votre serveur de jeux). Lors de l'écriture de données sur le serveur, vous le feriez normalement combiner un ensemble de modifications à votre structure de données en mémoire, et ensuite envoyer les mises à jour qu'une seule requête HTTP PUT pour le serveur.

Vous devez récupérer une copie de Richardson et de Rubis Services Web RESTfulqui est vraiment un excellent livre sur la conception de services web REST et explique les choses beaucoup plus clairement que je le pouvais. Si vous travaillez en Java je recommande fortement le RESTlet framework, qui très fidèlement les modèles le RESTE des concepts. Roy Fielding de l' USC thèse de définir le RESTE principes peuvent également être utiles.

Answer 5

Un type de support doit être rarement créé et l'heure doivent être investis pour assurer que le format peut survivre à changer.

Comme vous êtes en s'appuyant sur xml, il n'y a aucune raison pourquoi vous ne pourriez pas créer un type de support, à condition que le type de média est décrit dans une source.

Le choix de l'ATOME d'avoir un hôte de type de média qui prend en charge plusieurs éléments racine n'est pas nécessairement vous apporter quelque chose: vous aurez toujours besoin pour commencer la lecture du message dans le cadre d'une opération spécifique avant de décider si un nombre suffisant d'informations est présent pour traiter la demande.

Donc, je suggère que vous pourriez heureusement un type de média, représenté par un élément racine, et l'utilisation d'un langage de schéma pour spécifier les éléments qui peuvent être contenus.

En d'autres termes, une langue comme xsd pouvez vous permettre de taper votre type de média pour soutenir l'un des multiples éléments racines. Il n'y a rien d'intrinsèquement mauvais avec l'application/vnd.acme.ressourceshumaines+xml décrivant un document xml qui peut prendre l'une ou l'autre ou comme un élément racine.

Donc, pour répondre à votre question, créer des quelques types de médias que vous pouvez éventuellement se permettre de remettre en cause si ce que vous mettez dans la documentation du type de support sera compréhensible et implementeable par un développeur.