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

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 en fonction de l'application a besoin.

À 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}

Lu 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).

POUR: réduire le nombre d'objets, pas de traversée de hiérarchies d'objets requis

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}

Lu l'Utilisateur de l'objet (des ressources) et le retour de l'objet Utilisateur données Utilisateur peuplée et 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).

PROS: 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 type de service.

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

Dans ma recherche j'ai trouvé aussi cette série d'articles que j'ai trouvé très utile et accessible: infoq.com/minibooks/emag-03-2010-rest
Si vous êtes à la recherche pour l'un basé sur JSON type de support pour tous les styles, envisager de Shoji: aminus.org/rbre/shoji/shoji-draft-02.txt

InformationsquelleAutor paulkmoore | 2010-10-05

39

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 – retour 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 plein de vues ({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.
- Excellente façon de le mettre.
- Piet - merci beaucoup pour ce, il est très utile. Je tiens à préciser ce point, à propos de la traversée de données à partir d'un point de vue humain. Ma pensée est que si je fournis une liste des "à côté" des ressources plutôt que d'un "plein la vue" je permettre à l'utilisateur de consulter ce qu'ils veulent, à lire attentivement, et, par conséquent, de fournir une liste de liens est "plus" Reposante (conforme mieux à HATEOS). Je pouvais comprendre que le fait de fournir une peuplé liste est utile pour des raisons de performances, cependant. Je sais que c'est un peu du cas d'utilisation dépendante, mais je me demande si je ferais mieux de garder l'interface plus simple (et peut-être plus lent) pour le moment?
- Comment voulez-vous créer de tels objets hiérarchiques? par exemple, disons que nous avons de la bibliothèque -> livres -> chapitres -> pages. Maintenant, une approche pourrait être de créer un volumineux objet de la bibliothèque, mais quelle est l'alternative? Devriez-vous créer une bibliothèque d'abord, obtenir l'id et le réserver et ainsi de suite.
InformationsquelleAutor Pi Delport
25

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.
- Darrel - merci pour ce - aussi très utile. Je me doutais qu'il y avait une subtilité autour de l'objet de la cartographie que j'ai été absent. Je suis à la conclusion que, si je peux appeler sur mon objet existant cadre, j'ai besoin de concevoir soigneusement mes ressources "affichage". Merci.
InformationsquelleAutor Darrel Miller
9

Je recommanderais 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.

InformationsquelleAutor Yasir Hantoush
6

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. Conclure - 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, le 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

InformationsquelleAutor paulkmoore

Vous devez vous connecter pour publier un commentaire.