Comment dois-je traiter avec les hiérarchies de supports dans une API RESTful?

Question

Je suis actuellement à la conception de l'API pour une application en PHP, et, à cette fin étudie RESTE raisonnable approche architecturale.

Je crois que j'ai une assez bonne compréhension des concepts clés, mais j'ai du mal à trouver quelqu'un qui a abordé les hiérarchies de supports et de REPOS.

Voici le problème...

Dans la [demande] l'entreprise objet de la hiérarchie, nous avons:

Users 
 L which have one-to-many Channel objects
 L which have one-to-many Member objects

Dans l'application elle-même, nous utilisons un lazy load approche pour remplir l'objet de l'Utilisateur avec les tableaux de ces objets en tant que de besoin. Je crois OO termes c'est l'objet de l'agrégation, mais j'ai vu plusieurs de nommage des incohérences et ne se soucient pas de se lancer dans une guerre sur la convention de nommage .

Pour l'instant, considérez que j'ai quelques faiblement couplées, les objets que je peut / ne peut pas remplir selon l'application.

À partir d'un RESTE point de vue, je suis en train d'essayer de déterminer ce que l'approche devrait être. Voici ma pensée actuelle (compte tenu d'OBTENIR seulement pour le moment):

Option 1 - remplir entièrement les objets:

GET api.example.com/user/{user_id}

Lire l'Utilisateur de l'objet (des ressources) et de retour de l'objet Utilisateur avec tous les Canaux et Membre des objets pré-chargé et codé (JSON ou XML).

AVANTAGES: réduire le nombre d'objets, pas de traversée de l'objet des hiérarchies nécessaires
INCONVÉNIENTS: les objets doivent être entièrement rempli (cher)

Option 2 - remplir l'objet primaire et inclure des liens vers d'autres objets de ressources:

GET api.example.com/user/{user_id}

Lire l'Utilisateur de l'objet (des ressources) et le retour de l'objet Utilisateur données Utilisateur peuplées et les deux listes.

Chaque liste de références appropriées (sous -) c'est à dire des ressources

api.example.com/channel/{channel_id}
api.example.com/member/{member_id}

Je pense que c'est près de (ou exactement) les implications de l'hypermédia, le client peut obtenir les autres ressources si l'on veut (tant que je les marquer sagement).

Avantages: le client peut choisir de charger les subordonnés ou autrement, une meilleure séparation des objets comme les autres ressources
INCONVÉNIENTS: davantage de voyage requis pour obtenir les ressources secondaires

Option 3 - activer récursive récupère

GET api.example.com/user/{user_id}

Lire l'objet Utilisateur et inclure des liens vers des listes de sous-objets, c'est à dire

api.example.com/user/{user_id}/channels
api.example.com/user/{user_id}/members

la /les canaux d'appel de renvoyer une liste de canaliser les ressources dans la forme (comme ci-dessus):

api.example.com/channel/{channel_id}

PROS: ressources primaires exposer où aller pour obtenir de l'subodinates mais pas ce qu'ils sont (plus Reposant?), aucune exigence pour obtenir les subordonnés à l'avant, le subordonné liste des générateurs (et/ou les canaux et /membres) fournissent des interfaces (méthode) rendant la réponse plus service comme.
INCONVÉNIENTS: trois appels à maintenant nécessaire pour remplir entièrement l'objet

Option 4 - (re)considérer l'objet de la conception pour le REPOS

Je suis re-à l'aide de la [existant] objet de l'application de la hiérarchie et en essayant de l'appliquer au REPOS - ou peut-être plus directement, de fournir une API d'interface.

Peut-être le RESTE de la hiérarchie objet doit être différent, ou peut-être la nouvelle Reposante de la pensée est d'exposer les limites de l'objet existant conception.

Toute réflexion sur le dessus de bienvenue.

Merci beaucoup

Paul

Answer 1

Il n'y a aucune raison de ne pas combiner ces.

• api.example.com/user/{user_id} – retour d'un utilisateur de la représentation
• api.example.com/channel/{channel_id} – retour d'un canal de représentation
• api.example.com/user/{user_id}/channels – retourne une liste de canal représentations
• api.example.com/user/{user_id}/channel_list – retourner une liste d'id de canal (ou des liens vers leur pleine représentation, à l'aide des liens ci-dessus)

En cas de doute, pensez à comment vous afficher les données d'un utilisateur humain sans "API" préoccupations: un utilisateur veut à la fois les pages d'index ({user_id}/channel_list) et le plein de points de vue ({user_id}/channels).

Une fois que vous avez, en plus de soutenir JSON au lieu de (ou en plus) HTML comme format de représentation, et que vous avez de REPOS.

Answer 2

Le meilleur conseil que je puisse vous donner est d'essayer et d'éviter de penser au sujet de votre api REST comme le fait d'exposer vos objets. Les ressources que vous créez doit s'appuyer le cas d'utilisation dont vous avez besoin. Si nécessaire, vous pouvez créer des ressources pour l'ensemble des trois options:

api.example.com/completeuser/{id}
api.example.com/linkeduser/{id}
api.example.com/lightweightuser/{id}

Bien évidemment mes noms sont un peu maladroit, mais il n'a vraiment pas d'importance ce que vous les appelez. L'idée est que vous utilisez l'api REST pour présenter des données de la façon la plus logique pour le scénario d'utilisation. S'il y a plusieurs scénarios, de créer de multiples ressources, si nécessaire. J'aime à penser que mes ressources plus comme de l'INTERFACE utilisateur des modèles plutôt que des entités commerciales.

Answer 3

Je recommande Reposant Obects qui est des normes pour exposer un modèle de domaine est reposant

L'idée de Réparateur d'Objets est de fournir une norme générique interface RESTful pour le domaine des modèles d'objet, d'exposer des représentations de leur structure à l'aide de JSON et permettant des interactions avec le domaine d'instances de l'objet à l'aide de HTTP GET, POST, PUT et DELETE.

Selon la norme, l'Uri sera comme:

• api.example.com/object/user/31
• api.example.com/object/user/31/properties/username
• api.example.com/object/user/31/collections/channels
• api.example.com/object/user/31/collections/members
• api.example.com/object/user/31/actions/someFunction
• api.example.com/object/user/31/actions/someFunction/invoke

Il y a aussi d'autres ressources

• api.example.com/services
• api.example.com/domain-types

La spécification définit un peu primaire représentations:

• objet (qui représente n'importe quel domaine d'objet ou de service)
• (liste de liens vers d'autres objets)
• propriété
• collection
• action
• action résultat (contenant généralement un objet ou une liste, ou tout simplement des messages de commentaires)
• et aussi un petit nombre de secondaire des représentations telles que la maison, et l'utilisateur

Ce qui est intéressant, comme vous allez voir que les représentations sont entièrement auto-descriptif, en ouvrant la possibilité de générique de téléspectateurs à être mis en œuvre si nécessaire.

Sinon, les représentations peuvent être consommés directement par une application sur mesure.

Answer 4

Voici mes conclusions de nombreuses heures de recherche et avec l'apport des intervenants ici:

Où j'ai un objet qui est en fait un multi-partie de l'objet, j'ai besoin de traiter que d'une seule ressource. Donc si je REÇOIS l'objet, tous les sous-coordonnées devraient être présents. Ceci est nécessaire afin que la ressource est mis en cache. Si je charge partielle de l'objet (et de fournir un ETag timbre), puis d'autres demandeurs peuvent recevoir seulement une partie de l'objet quand ils devraient plein. Concluons - les objets doivent être remplis si ils sont disponibles en tant que ressources.

Associés les relations d'objet doit être mis à la disposition que des liens à d'autres (primaire) des ressources. De cette façon, les objets sont trouvables en parcourant l'API.

Aussi, la hiérarchie de l'objet qui fait sens pour l'application principale du site peuvent sembler ne pas être ce dont vous avez besoin à la loi sur le repos manière, mais il est plus probable révélant des problèmes avec la hiérarchie existante. Cela dit, l'API peut exiger plus spécialisés des cas d'utilisation que ce qui avait été prévu, et des ressources spécialisés peuvent être nécessaires.

Espère que ça aide quelqu'un