Bonjour,
je suis entrain de construire des API. Le référent API me demande de mettre en place la pagination. Je n’ai pas pu trouver une réponse dans la documentation. Existe-t-il un moyen de gérer la pagination lors de la construction de mes APIs ?
Je souhaiterai aussi savoir, est-il possible de pré-filtrer une requête au moment de la configuration de l’url/mapping, au moment de la construction de ma classe java d’API ?
Qu’est ce que vous appelez “mes APIs” / “custom REST API” ?
Pour ce qui est de votre "est-il possible de pré-filtrer une requête au moment de la configuration de l’url/mapping, au moment de la construction de ma classe java d’API " je ne suis pas sûr de comprendre la question mais le filtrage d’un objet se met en place au niveau de l’objet, certainement pas au niveau d’une couche d’accès à cet objet (IHM ou API). Une couche d’accès n’est qu’une couche technique et protocolaire qui ne doit pas avoir d’intelligence métier, le faire serait un contre-sens vis à vis de la logique de Simplicité.
En fait, je construit une API à partir d’une classe qui étend la classe RESTMappedObjectsExternalObject.
Je vais illustrer par un exemple ci-dessous:
Soient une api “apitest” et un objet étier “personnes”. Pour avoir la liste des personnes de role leader, on a l’url /apitest/personnes?role= leader.
Ma question est de savoir si c’est possible d’avoir un pré-filtrage c’est à dire :
une ressource “leaders” et une ressource “productOwner” tels que ci-dessous:
/apitest/leaders/ qui donnerait le même résultat que /apitest/personnes?role= leader,
/apitest/productOwner/ qui donnerait le même résultat que /apitest/personnes?role= po,
La classe helper RESTMappedObjectsExternalObject ne fait qu’un sous ensemble de fonctionnalités restreint vis à vis de ce que font les APIs REST standard. Je vais vérifier mais je ne pense pas qu’elle gère de pagination (contrairement aux services REST standard).
Quelles sont vos préconisations/specifications/normes pour ce qui est de la gestion de la pagination ?
Pour rappel cette classe a été développée pour répondre à vos normes et contraintes spécifiques en termes de structuration d’APIs (qui ne sont pas compatibles avec nos APIs standard).
Il n’est donc pas du tout logique de nous demander si cette classe fait ci ou ça dans la mesure où elle ne fait que ce que vous avez demandé.
Bref si vous avez besoin qu’elle fasse quelque chose de plus que ce qu’elle fait aujourd’hui, merci de le specifier précisément.
Pour ce qui est de la 2ème question je le redis, ce n’est pas pertinent/souhaitable de demander à une couche de publication API de gérer des règles de gestion métier.
Pour faire les choses correctement dans votre cas il faudrait paramétrer un modèle métier conforme à votre besoin à savoir un objet père Personne dont héritent 2 objets fils Leader et ProductOwner avec chacun le filtrage statique (i.e. “search spec” dans le vocabulaire Simplicité) qui va bien. Et au passage l’avantage d’un tel modèle c’est de pouvoir habiliter chaque objet finement si besoin.
Au niveau de votre API custom vous mappez ensuite Personne sur /apitest/personnes , Leader sur /apitest/leaders et ProductOwners sur /apitest/productOwners.
merci beaucoup pour ta réponse. En effet, nous prévoyions effectivement de nous baser sur un mécanisme d’héritage pour pré-filtrer certaines ressources (dans le preSearch en l’occurrence) dans le contexte d’API spécifiques.
Toutefois, j’avais demandé à Alexandre de vérifier auprès de vous si il n’était pas possible de spécifier ce filtre dans le mapping d’URL afin d’éviter de mettre en œuvre l’héritage/preSearch.
Le post d’Alexandre fait suite à une revue par notre “expert API” qui avait émis plusieurs réserves / non-conformités. J’ai passé en revue hier soir tous les points identifiés comme « non-conformes » et nous nous sommes finalement accordés sur deux non-conformités. Les autres points relèvent de l’interprétation ou d’évolutions (dont la pagination et le tri) qui n’ont pas encore été spécifiées dans l’API design guide qui est toujours d’actualité chez-nous. Je te le renvoie par MP avec le détail des deux non-conformités restantes.
à nouveau, merci beaucoup pour ton support et ton expertise.