Custom REST API - pagination - tri - filtre

Custom REST API - pagination - tri - filtre
0
Tags: #<Tag:0x00007f3958427168>

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 ?

Ci-dessous, le health de l’environnement

[Platform]
Status=OK
Version=4.0.P23
BuiltOn=2019-05-28 20:50 (revision b4dcc121cee1b86e41ba9d3091d49d85726fd4c3)
Encoding=UTF-8
EndpointIP=21.0.9.2
EndpointURL=http://5cc7b35afb76:8080
TimeZone=Europe/Paris
SystemDate=2019-06-05 11:04:27

[Application]
ApplicationVersion=4.0
ContextPath=
ContextURL=https://bca.dok-dev.intra.renault.fr
SessionLogin=p096790
SessionID=DD87431A572DD7ED11CCBD9B2D95E36F
SessionUserAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
ActiveSessions=4
EnabledUsers=844
TotalUsers=3565
LastLoginDate=2019-06-05 10:19:22

[Server]
ServerInfo=Apache Tomcat/9.0.20
ServerType=WEB
User=root

[OS]
Name=Linux
Architecture=amd64
Version=3.10.0-957.12.1.el7.x86_64
SystemEncoding=UTF-8

[Disk]
DiskFree=387593
DiskUsable=387593
DiskTotal=510726

[JavaVM]
Version=1.8.0_212
Vendor=Oracle Corporation
VMName=OpenJDK 64-Bit Server VM
VMVersion=25.212-b04
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.10 2018 04 09
HeapFree=365373
HeapSize=1107456
HeapMaxSize=2275840
TotalFreeSize=1533757

[Cache]
GrantCache=58
GrantCacheMax=0
GrantCacheRatio=0
ObjectCache=400
ObjectCacheMax=10000
ObjectCacheRatio=4
ProcessCache=0
ProcessCacheMax=10000
ProcessCacheRatio=0

[Database]
Vendor=2
ProductName=MySQL
ProductVersion=5.5.45-log
DriverName=MySQL Connector/J
DriverVersion=mysql-connector-java-8.0.15 (Revision: 79a4336f140499bd22dd07f02b708e163844e3d5)
DBDate=2019-06-05 11:04:27
DBDateOffset=0
DBPatchLevel=P23
UsingBLOBs=true

[Healthcheck]
Date=2019-06-05 11:04:27
ElapsedTime=15

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,

Cdt

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.

Toute autre approche serait du “bricolage”.

Bonjour David,

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.

Bruno