Opowiedz o zasadzie HATEOAS.

HATEOAS (Hypermedia jako silnik stanu aplikacji) jest kluczową zasadą usług RESTful. Zakłada, że klient powinien przechodzić między stanami aplikacji wyłącznie za pomocą hipermedialnych odnośników dostarczanych przez serwer w odpowiedziach. To sprawia, że API jest samo-detekcyjne i mniej sztywno powiązane z konkretnymi URL-ami, zwiększając jego elastyczność i skalowalność.

Wyobraźmy sobie, że otrzymujemy informacje o zamówieniu. Bez HATEOAS odpowiedź może wyglądać tak:

{
  "order_id": 123,
  "status": "pending",
  "total": 100.50
}

Aby wykonać działania na tym zamówieniu (np. zapłatę lub anulowanie), klient musi znać wcześniej odpowiednie URL-e i metody HTTP.

Z HATEOAS serwer dołącza do odpowiedzi linki do dostępnych działań:

{
  "order_id": 123,
  "status": "pending",
  "total": 100.50,
  "_links": {
    "self": { "href": "/api/orders/123" },
    "pay": { "href": "/api/orders/123/pay", "method": "POST" },
    "cancel": { "href": "/api/orders/123/cancel", "method": "PUT" }
  }
}

Teraz klient, otrzymując tę odpowiedź, widzi dostępne działania (pay, cancel) i ich URL-e, nie mając wcześniejszej wiedzy o strukturze API. Jeśli serwer zdecyduje się zmienić URL płatności, klient otrzyma zaktualizowany link w odpowiedzi i będzie mógł kontynuować bez konieczności zmiany kodu.

Zalety HATEOAS:

• Elastyczność: API staje się mniej sztywne względem konkretnych URL-i. Zmiany w strukturze lub URL-ach nie wymagają przebudowy klienta.
• Samodetekcja: Klient może eksplorować API, podążając za linkami w odpowiedziach.
• Ewolucja API: Serwer może dodawać nowe funkcje (np. nowe linki) lub usuwać stare, a klient będzie się do nich dostosowywał.

Wady HATEOAS:

• Złożoność implementacji: Serwer musi generować i dołączać linki do każdej odpowiedzi, co może być trudniejsze.
• Większe odpowiedzi: Odpowiedzi stają się większe z powodu dołączenia hipermedialnych linków.
• Złożoność klienta: Logika klienta musi być dostosowana do obsługi i podążania za hipermedialnymi linkami.

W QA / Automatyzacji QA testowanie API korzystającego z HATEOAS wymaga specjalnego podejścia. Zamiast twardo kodować URL-e w testach, należy wyodrębnić linki z odpowiedzi i używać ich do kolejnych żądań. To czyni testy bardziej odpornymi na zmiany w API. Przykład w Java z RestAssured:

// Pobranie informacji o zamówieniu
Response orderResponse = given()
    .when()
    .get("/api/orders/123")
    .then()
    .statusCode(200)
    .extract().response();

// Wyodrębnienie URL płatności z hipermedialnych linków
String payUrl = orderResponse.jsonPath().getString("_links.pay.href");
String payMethod = orderResponse.jsonPath().getString("_links.pay.method");

// Wykonanie żądania płatności z wyodrębnionymi danymi
given()
    .when()
    .request(payMethod, payUrl) // Zamiast stałego URL
    .then()
    .statusCode(200);

W ten sposób HATEOAS jest ważnym zasadą tworzenia prawdziwie RESTful API, zwiększającą elastyczność i użyteczność. Dla testerów oznacza to konieczność dostosowania strategii testowania do pracy z dynamicznymi hipermedialnymi linkami.