narażając REST punkty końcowe dla jednego do wielu relacji

Question

Rozważmy następującą relację między dwoma zasobów

• College ma wiele Wydziały
• Wydział należą do College

Oczywiście Wydział nie jest tutaj zasobem pierwszej klasy.

Teraz potrzebuję punktów końcowych dla następujących operacji.

• Utwórz nowy wydział w tej uczelni tej farmy. Jeden z możliwych sposobów na zrobienie tego w dwóch operacjach.
  • POST /faculties/
  • PUT /college/1/faculties
• Usuwanie wykładowców z tej uczelni. Ponownie dwie operacje
  • GET /college/1/faculties: Lista skojarzonych zdolności. Każdy będzie zawierał własny adres URL, taki jak /faculties/1.
  • DELETE /college/1/faculties/1: Adres URL wygląda lepiej, ale jak wyświetlić ten adres URL?
• Dodaj jedno lub więcej wydziałów w ramach tej uczelni.
  • PUT /college/1/faculties który akceptuje pełną listę wydziałów tej uczelni.
• Usuń ten konkretny sektor w całości.
  • DELETE /sectors/1: Wygląda dobrze, ale musi dbać o pamięć podręczną /faculties/1/sectors.

Co byłoby lepszym rozwiązaniem w tym przypadku? Czytałem o wystawianiu zasobów członkowskich, ale z takim podejściem, jeśli szkoła ma 10 wydziałów, to zajmie 10 osobnych połączeń http, aby uzyskać wszystkie z członkostw.

Co więcej, jest to tylko niewielka część pełnego drzewa relacji. W tym celu sięgają dalej, twierdzą, że system ma

• wydziałów ma wiele wydziałów
• dział ma wiele laboratoriów itd.

Ponadto w architekturze RESTful klient nie powinien wypełniać adresów URL.

Jakieś sugestie?

Answer 1

Napisałem post w przeszłości o tym, jak OData implementuje takie aspekty (funkcja "właściwości nawigacyjne"). Zobacz ten link: https://templth.wordpress.com/2014/12/08/updating-data-links-of-odata-v4-services-with-olingo/.

Ten drugi link może również dać ci kilka interesujących wskazówek, ponieważ opisuje na końcu adresy URL i odpowiednie ładunki: http://www.asp.net/web-api/overview/odata-support-in-aspnet-web-api/odata-v4/entity-relations-in-odata-v4.

Sądzę, że istnieją dwa przypadki, w których można wykorzystać efekt dźwigni, aby zminimalizować liczbę żądań: praca z referencją lub dostarczanie treści. Mam na myśli to, że zasób wykrywa (w oparciu o zawartość lub niestandardowy nagłówek) wysłaną zawartość, aby wiedzieć, czy potrzebuje tylko obsługi odniesienia (tylko załącznik) lub treści (tworzenie i dołączanie).

chciałbym zobaczyć następujące ewentualne wnioski o wielokrotnej liczności (college -> wydziały):

• POST /faculties/: dodaj wydział bez przywiązania do kolegium
• POST /college/1/faculties: dołączanie zdolność do college'u i ostatecznie utwórz go, jeśli nie istnieje (na podstawie przesłanej zawartości)
• DELETE /college/1/faculties/?ref=/faculties/1 aby odłączyć wykładowców z uczelni

Coś, co można również rozważyć, to umieszczenie odniesienia do kolegium na wydziale (żądanie POST /faculties). Możesz więc dołączyć element podczas jego tworzenia.

W przeciwnym razie zmiana ta ma na celu zastąpienie całej reprezentacji wszystkich wydziałów przypisanych do konkretnej uczelni.

Można również użyć metody POST lub PATCH, aby zminimalizować liczbę żądań. Możesz zapoznać się z tymi odpowiedziami, aby uzyskać więcej informacji: REST API - Bulk Create or Update in single request i How to Update a REST Resource Collection. Takie podejście pozwala tworzyć elementy w jednym wywołaniu, a następnie je dołączać. Pozwala to na gromadzenie przetwarzania na elementach.

nadzieję, że było jasne, a to pomaga, Thierry

Answer 2

Zastosowanie:

• POST: tworzenie nowych rekordów.
• PUT: edycja istniejących rekordów.
• USUŃ: aby usunąć istniejące rekordy.
• GET: pobieranie pojedynczego lub listy rekordów.

Oto standardowe metody stosowane w utrzymywaniu utrwalonych danych.

I nie mieszaj relacji encji z adresami punktów końcowych. Traktuj każdy obiekt w punktach końcowych tak, jakby nie było między nimi związku. I zawsze w liczbie pojedynczej twój punkt końcowy kończy się faculty, a nie faculties.

POST /college/ 
POST /faculty/ 
POST /department/ 
POST /lab/ 

Jeśli trzeba odróżnić powracający z listy rekordów z jednego rekordu, zawsze zwraca listę rekordów z wykorzystaniem GET i powrotu pojedynczy rekord używając GET z parametrem ID. Ta sama metoda i ten sam punkt końcowy może być wykorzystana do pobrania obu (lista i pojedynczy rekord). Nie ma potrzeby tworzenia różnych punktów końcowych do pobierania list i pojedynczych rekordów.