REST Hateos: Comment s'assurer que le client entre l'application REST via une URL fixe simple?

Question

Nous voulons créer un écran sur plusieurs clients qui affiche «5 produits les plus vendus», «5 produits récemment ajoutés» et «5 produits avec d'excellentes offres». Tout cela serait montré comme carrousel.

Nous voulons créer des API reposantes pour ceux-ci. Nous avons créé des API suivantes:

1. /api/bestsellingproduct/
2. /api/recentlyaddedproduct/
3. /api/greatofferproduct/

Actuellement, chaque client par exemple bureau, mobile, Android, ios a codé en dur ces URI. Je suis inquiet si nous modifions demain ces URL, il serait lourd et REST suggère que "Un client REST entre dans une application REST à travers une URL fixe simple." (Ref: https://en.wikipedia.org/wiki/HATEOAS) "

Quelqu'un peut-il suggérer comment je peux assurer que tous les clients entrent l'application par l'URL fixe simple dans ce cas?

Answer 1

Dans HATEOAS, les URI sont détectables (et non documentés) afin de pouvoir être modifiés. C'est-à-dire, à moins qu'ils ne soient les points d'entrée dans votre système (Cool URIs, les seuls qui peuvent être codés en dur par les clients) - et vous ne devriez pas en avoir trop si vous voulez pouvoir faire évoluer le reste de votre structure URI du système dans le futur. C'est en fait l'une des fonctionnalités les plus useful de REST. Pour les URI non-Cool restants, ils peuvent être changés au fil du temps, et votre documentation API devrait indiquer qu'ils doivent être découverts lors de l'exécution via une traversée hypermédia.

En regardant le Richardson's Maturity Model (level 3), ce serait là que les liens entrent en jeu. Par exemple, à partir du niveau supérieur, dites/api/version (/ 1), vous découvrirez qu'il y a un lien vers les groupes. Voici comment cela pourrait regarder dans un outil comme HAL Browser:

Racine:

{ 
    "_links": { 
    "self": { 
     "href": "/api/root" 
    }, 
    "api:bestsellingproduct": { 
     "href": "http://apiname:port/api/bestsellingproduct" 
    }, 
    "api:recentlyaddedproduct": { 
     "href": "http://apiname:port/api/recentlyaddedproduct" 
    }, 
    "api:greatofferproduct": { 
     "href": "http://apiname:port/api/greatofferproduct") 
    } 
    } 
} 

L'avantage ici serait que le client aurait seulement besoin de connaître la relation (lien) nom (bien évidemment en plus de la structure des ressources/properties), alors que le serveur serait principalement libre de modifier l'URL de la relation (et de la ressource).

Vous pouvez même les intégrer à retourner dans le même appel api racine:

{ 
    "_embedded": { 
    "bestsellingproduct": [ 
     {    
      "id": "1", 
      "name": "prod test" 
     }, 
     {    
      "id": "2", 
      "name": "prod test 2" 
     } 
    ], 
    "recentlyaddedproduct": [ 
     {    
      "id": "3", 
      "name": "prod test 3" 
     }, 
     {    
      "id": "5", 
      "name": "prod test 5" 
     } 
    ] 
}