REST Hateos: Wie kann sichergestellt werden, dass der Client eine REST-Anwendung über eine einfache feste URL eingibt?

Question

Wir möchten einen Bildschirm auf mehreren Clients erstellen, der "5 meistverkaufte Produkte", "5 kürzlich hinzugefügte Produkte" und "5 Produkte mit tollen Angeboten" anzeigt. All dies würde als Karussell angezeigt werden.

Wir möchten Restful APIs für diese erstellen. Wir haben folgende APIs erstellt:

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

Derzeit jeder Kunde also Desktop, Mobile, Android, IOS hat diese URIs hart-codiert. Ich bin besorgt, wenn wir diese URLs morgen ändern, wäre es umständlich und auch REST schlägt vor, dass "Ein REST-Client eine REST-Anwendung durch eine einfache feste URL eingibt. (Ref: https://en.wikipedia.org/wiki/HATEOAS)"

Kann jemand vorschlagen, wie ich sicherstellen kann dass alle Kunden in diesem Fall eine Anwendung über eine einfache feste URL eingeben?

Answer 1

In HATEOAS sind URIs erkennbar (und nicht dokumentiert), so dass sie geändert werden können. Das heißt, es sei denn, sie sind die eigentlichen Einstiegspunkte in Ihr System (Cool URIs, die einzigen, die von Clients hartcodiert werden können) - und Sie sollten nicht zu viele davon haben, wenn Sie die Fähigkeit haben möchten, den Rest Ihres Systems weiterzuentwickeln System-URI-Struktur in der Zukunft. Dies ist in der Tat eine der useful Features von REST.

Für die verbleibenden nicht-coolen URIs können sie im Laufe der Zeit geändert werden, und Ihre API-Dokumentation sollte die Tatsache buchstabieren, dass sie zur Laufzeit durch Hypermedia Traversal entdeckt werden sollten.

Mit Blick auf die Richardson's Maturity Model (level 3), dies wäre, wo Links ins Spiel kommen. Zum Beispiel würden Sie von der obersten Ebene, sagen wir/API/Version (/ 1), entdecken, dass es eine Verbindung zu den Gruppen gibt. Hier ist, wie dies in einem Tool wie HAL Browser aussehen könnte:

Root:

{ 
    "_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") 
    } 
    } 
} 

Der Vorteil wäre, dass der Kunde würde nur wissen müssen, um die Beziehung (Link) Name (auch offensichtlich neben der Ressourcenstruktur/Eigenschaften), während der Server weitgehend frei wäre, die Beziehungs- (und Ressourcen-) URL zu ändern. in der gleichen Wurzel api-Aufruf zurückgegeben werden

Man könnte sie sogar einbetten:

{ 
    "_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" 
     } 
    ] 
}