Projektowanie interfejsu REST API: łączenie zasobów

Question

Zakładam, że mam dwa zasoby najwyższego poziomu: Foo i Bar. Teraz Foo muszą być połączone z niektórymi z Bar. W klasie Java może to wyglądać mniej więcej tak:

public class Foo { 

    Set<Bar> bars; 
} 

public class Bar { … } 

Chciałbym kształtować reprezentację XML Foo aby coś takiego:

GET /foos/1 

<foo> 
    … 
    <atom:link rel="self" href="/foos/1" /> 
    <atom:link rel="bars" href="/foos/1/bars" /> 
</foo> 

Więc dość dużo wystawiać wszystkie Barprzypisany do Foo jako zasób zagnieżdżony. Oznacza to, że zasoby mają indywidualny cykl życia (agregacja zamiast kompozycji). Zasób zagnieżdżony może wtedy wystawiać wszystkich połączonych Bar coś takiego:

GET /foos/1/bars 

<bars> 
    <atom:link rel="bar" href="/foos/1/bars/1" /> 
    <atom:link rel="bar" href="/foos/1/bars/2" /> 
</bars> 

Alteratively mogłem Inline kolekcję w <foo> elementem góry. Jednak wciąż mam kilka pytań: podczas gdy to pozwala mi ładnie usunąć Bar z Foo przez wywołanie żądania do np. DELETE/foos/1/bars/1, ale w jaki sposób przypisałbym wtedy Bar do Foo? Zakładając, że klient będzie uzyskanie dostępu /bars:

GET /bars 

<bars> 
    <bar> 
    … 
    <atom:link rel="self" href="/bars/4711" /> 
    </bar> 
</bars> 

i decydując chce przypisać /bars/1 do /foo/1/bars. Myślałem o zgłoszeniu POST do /foo/1/bars, ale nie byłem pewien, co przesłać. Element link wskazuje na zasób Bar, taki jak poniższy?

POST /foos/1/bars 

<atom:link href="/bars/4711" /> 

Wydaje się to całkiem w porządku, ponieważ klienci wciąż nie będą musieli tworzyć adresów URL i nadal będziemy spełniać ograniczenia REST. Jednak wydaje się nieco dziwne, jeśli chodzi o linki do serwera. Czy istnieje lepsze rozwiązanie tego scenariusza?

Answer 1

Myślę o tym w kategoriach zasobów rozumianych przez serwer, a nie reprezentacji XML, które płyną w odpowiedzi na (powiedzmy) żądanie GET. Mam usługi RESTful, które zwracają JSON lub XML, lub potencjalnie inne reprezentacje.

Tak zgadzam się z komentarz lub oddanie do

/foos/{fooId}/bars 

określić zarówno pełną listę barów lub dodanie kilku barów.

Format przesyłanego ładunku może być dowolny, niezależnie od tego, jaki jest naturalny, zserializowany formularz dla typu mediów, z których korzysta użytkownik. W moim przypadku jest to często ciąg znaków JSON, więc w mojej implementacji usługi deserializowałaby się i wyświetlała tablicę referencyjnych ciągów URL odsyłania.

Jeśli Twój

<atom:link href="/bars/4711" /> 

również deserialise ładnie to ja nie widzę problemu, jeśli formularz odcinkach jest trochę, hm, ozdobnych.

Podsumowanie: rób to, co naturalne dla twojego serializera (de).