API Rest - défis spécifiques aux mobiles

Je travaille sur un nouveau projet d'application iOS, côté mobile. Certains changements d'architecture sont en cours et il s'avère que nous devrons compter sur une API privée personnalisée qui sera utilisée par l'application que nous construisons et également par d'autres clients tels qu'un site Web.

L'API en cours de conception suit le style Rest des opérations URI et CRUD centrées sur les ressources mappées aux verbes HTTP. des choses comme:

GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793

Le problème est que ce style entraîne souvent la nécessité pour le client mobile de faire de nombreuses demandes pour charger un seul écran d'application ou gérer une seule action d'interface utilisateur. Cela conduit à l'application en mode de chargement pendant 8 secondes jusqu'à ce qu'elle ait tout le nécessaire. Une application lente et qui ne répond pas.

Les clients mobiles ont de sérieuses limitations en matière de connectivité et donc idéalement, nous devrions suivre ce genre de règle:

1 écran == 1 appel API

1 sauvegarde == 1 appel API.

Il existe de nombreuses situations où cela vous met sur une trajectoire de collision avec les principes de conception REST, par exemple:

• disons que votre application est hors ligne depuis un jour et que vous devez vous synchroniser avec quatre tables des bases de données principales et que vous avez besoin d'un appel comme www.example.com/sync_everything?since=2015-07-24
• disons qu'il y a un écran où l'utilisateur peut éditer plusieurs de ses objets, par exemple en cochant des tâches dans sa liste de tâches. il devrait y avoir un moyen de modifier tous ces enregistrements de tâches en un seul appel d'API par lots plutôt qu'en un seul appel d'API par modification.
• disons qu'il y a un écran qui mélange les informations des tables db ORDER, SALESMEN et PRODUCT, je devrais obtenir ces données en un seul appel au lieu de trois.

le risque est que nous puissions nous retrouver avec l'API la plus reposante qui soit et aussi avec l'application mobile la plus inutile qui soit.

Le fait est que je ne suis qu'un nouvel entrepreneur là-bas et ce dont j'ai besoin, c'est de quelque chose qui m'aide à faire valoir ces points, de certains articles de sources bien respectées ou quelque chose comme ça. Les principaux acteurs faisant des compromis avec le style REST pour leur client mobile (par exemple: en utilisant des points de terminaison d'API d'agrégats composites).

Ou toute solution à ce problème général. Merci!

L'API en cours de conception suit le style Rest des opérations URI et CRUD centrées sur les ressources mappées aux verbes HTTP.

C'est votre problème ici.

Vous avez limité vos ressources (je suppose) aux modèles de votre base de données. En tant que tel, il faut du temps pour charger toutes ces ressources car votre serveur n'a aucun concept de ressources qui n'ont pas de représentation dans la base de données.

Par exemple, pourrait avoir

www.example.com/books/482094
www.example.com/books/582045
www.example.com/books/427454
www.example.com/books/319343

que tous doivent être chargés pour obtenir ma bibliothèque

Ce n'est pas un problème avec la conception RESTful, c'est en fait un anti-motif REST. Il n'y a absolument rien dans REST qui dit que nos ressources doivent avoir un mappage un à un avec tout autre élément de votre système, y compris les modèles de base de données.

La solution est de créer plus de ressources qui correspondent mieux à ce que vous souhaitez charger. Si vous avez 5 ressources qui finissent toujours ensemble, créez une nouvelle ressource qui contient les informations pour ces 5 ressources.

Vous devriez avoir quelque chose comme ça

www.example.com/users/334/my_library

qui charge juste tous les livres pour cet utilisateur. "my_library" n'est pas un modèle dans votre base de données, mais c'est une ressource. Le serveur le crée en fonction des modèles de la base de données, mais il n'y a pas de mappage 1 à 1 et le serveur a la possibilité de créer cette ressource sans modifier votre modèle de base de données.

Vous pourriez aussi avoir

www.example.com/users/334/favioured_books
www.example.com/users/334/books_ordered_last_week
www.example.com/users/334/wishlist

aucun d'entre eux ne doit exister en tant que modèle dans votre base de données ou votre espace de domaine.

Il y a une idée fausse largement répandue selon laquelle ce n'est pas la bonne chose à faire, car des cadres comme Rails ont appris aux gens à mapper les ressources de manière 1 à 1 aux modèles de l'espace de domaine qui mappent à nouveau 1 à 1 avec des lignes de base de données. Ce n'est ni nécessaire ni recommandé.

Les ressources doivent être nombreuses, bon marché et légères . Il doit être facile de les créer et ils doivent être extraits de votre modèle de domaine. Si vous trouvez que vous en avez besoin d'un nouveau, il vous suffit d'en créer un nouveau. Si vous avez des problèmes à le faire, c'est la faute de votre framework, pas une faute avec REST.

Maintenant, la grande mise en garde avec cela est bien sûr de savoir si votre cadre vous permet de le faire. Des frameworks comme Rails et Django qui ont suivi le cours de mappage 1 à 1 afin de "vous faire gagner du temps" compliquent la tâche. Mais c'est un défaut avec les cadres, pas avec la conception RESTful.

Voici Jim Webber discutant de cela plus en détail (y compris quelques fouilles sur Rails aussi!)

https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047