Połącz nagłówki i elementy linków dla RESTful JSON - json, web-services, http, reszta, http-headers

Podczas budowania API RESTful / hypermedia z zasobami JSON wydaje mi się, że mam dwie opcje do określenia hipermedialnych relacji między zasobami.

1. Osadź łącza w treści dokumentu JSON. Problem polega na tym, że nie ma standaryzowanej składni do określania hiperłączy, chociaż widzę wiele dobrych wysiłków: (HAL, Collection + JSON, JSON-LD, JSON Schema, aby wymienić tylko kilka).

2. Użyj nagłówków HTTP Link. Jest to standaryzacja, więc wydaje się, że ma przewagę nad linkami osadzonymi. Klienci po prostu wiedzą, jak rozumieć standardowy nagłówek i voila, osiąga się dobro hipermedialne.

A zatem, w kontekście obsługi zasobów JSON, jaki jest sposób i dlaczego?

Odpowiedzi:

12 dla odpowiedzi № 1

Idź z hipermedialnym formatem JSON. Chociaż nagłówki linków są standardem, są źle przyjęte, są bardziej odpowiednie dla formatów mediów, które nie są hipermedialne. Ale ponieważ masz wybór i możesz wybrać format hipermediów (w odróżnieniu od, powiedzmy, PNG kontra JPG), powinieneś po prostu wybrać jedną i iść do przodu.

Wszystkie standardy JSON przepełniają się, dopóki jeden lub drugi nie stanie się standardem "de facto". Im częściej są używane, tym bardziej "de facto" otrzymują.

Wydaje mi się, że HAL jest na solidnym torze Standardów i wybrałbym to.

Ale tak czy siak, idź z hipermedialnym formatem, ponieważ możesz.

---

10 dla odpowiedzi nr 2

Jeśli chcesz, aby twoje łącza były przetwarzane przez pośredników HTTP, zdecydowanie powinieneś użyć nagłówków linków. Jednym z przykładów jest Invalidation w powiązanej pamięci podręcznej:

http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-01

Jeśli chcesz tylko odsłonić linki do swoich klientów, lepiej jest umieścić je w encji, aby skorzystać z linków w obrębie elementów zagnieżdżonych:

{
"item": [
{ "name": "fork",  "href": "http://example.com/item/1" },
{ "name": "spoon", "href": "http://example.com/item/2" },
{ "name": "spork", "href": "http://example.com/item/3" }
],
"href": "http://example.com/items"
}

---

9 dla odpowiedzi nr 3

• Nagłówki linków mogą być rozważane przez pośredników
• Nagłówki linków są kompresowane przez SPDY
• Nagłówki linków są standardowe

W razie potrzeby mogą nawet zawierać JSON! http://tools.ietf.org/html/draft-nottingham-link-hint-00

Takie podejście umożliwia jednoczesne dostarczanie we wszystkich odpowiedziach:

• Nagłówki linków zawierające informacje hipermedialne
• ładunek poświęcony reprezentacji zasobów

Oczywiście reprezentacja zasobów może zawierać linki zakodowane w różnych formach, ale użycie nagłówków Link może stanowić najważniejszą część dynamicznej struktury Twojej witryny.

To, co sprawia, że ​​to rozwiązanie jest zdecydowanie atrakcyjne, to IMHO jako podpowiedź typu "accept-post".

---

5 dla odpowiedzi № 4

Nie możesz kompresować nagłówków, jeśli masz dużo linków, to może coś zmienić.

Udostępnianie kontekstu dla łącza. Nagłówki linków mają atrybut zakotwiczenia, ale nie ma standardowej składni ścieżki fragmentu, czyli YMMV.

Z góry mojej głowy nie mogę myśleć o żadnych innych plusach / minusach.

---

0 dla odpowiedzi № 5

Wydaje mi się, że używam obu alternatyw (Linknagłówki i linki hipermedialne w treści odpowiedzi w standardowym formacie, takim jak HAL), pozwalają Twojemu rozwiązaniu czerpać korzyści z obu podejść. Oczywiście, brzmi to jak dobry pomysł, jeśli twoja struktura REST wspiera automatyczne tworzenie linków w obu miejscach.

---