Czy interfejs API RESTful powinien udostępniać dane dla całego formularza?

13

Załóżmy, że mam aplikację internetową JavaScript, która całkowicie wykorzystuje interfejs API RESTful dla danych.

Załóżmy, że ta aplikacja ma formularz danych, i powiedzmy, że edytuję rekord w / product / 12345. Podczas budowania formularza wysyłam żądanie RESTful do / product / 12345 i otrzymuję dane JSON:

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27
}

Więc mój formularz może oczywiście zawierać listę rozwijaną do wyboru sprzedawcy. Muszę wypełnić tę listę. Skąd dane powinny pochodzić? Jakie jest najczęstsze podejście?

Czy sensowne byłoby uczynienie go częścią odpowiedzi na żądanie / product / 12345?

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27,
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ]
}

Co powiesz na temat tworzenia nowego rekordu? Czy mój interfejs API powinien również odpowiadać na GET / produkt / nowy, z następującymi pytaniami?

{
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ],
  "categories": [
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
  ],
  "etc": [ ... ]
}

api rest forms

— Chad Johnson
źródło

proszę nigdy nie używać żądania GET do tworzenia czegoś. Punktem końcowym powinien być / product not / product / new . Aby utworzyć nowy produkt, należy wysłać żądanie PUT do tego punktu końcowego.

— Kerem Baydoğan

To niczego nie tworzy. Jest to wyłącznie prośba o istniejące dane lub szablon nowego, jeszcze nie zapisanego rekordu.

— Chad Johnson

o przepraszam, teraz rozumiem co masz na myśli. w żadnym wypadku punkt końcowy produktu nie powinien być odpowiedzialny za dostarczenie produktu szablonu lub listy wartości dla list rozwijanych formularza tworzenia produktu. jak mówi @Dan, po prostu stwórz osobne punkty końcowe i użyj buforujących nagłówków, aby Twoja przeglądarka mogła buforować rozwijane wartości wydajności.

— Kerem Baydoğan

6

Opieram się na bardzo prostych, wąsko skoncentrowanych punktach końcowych. Oczekiwałbym żądania w niektórych lokalizacjach, takich jak / sales_users, które zwraca wszystkich użytkowników sprzedaży.

GET / sales_users:

[
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
]

Podobnie, jeśli masz mieć listę kategorii, dodałbym do tego osobny punkt końcowy.

POBIERZ / kategorie:

[
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
]

Nie zbudowałbym GET / produktu / nowego. Zamiast tego zbudowałbym w Twojej aplikacji formularz do obsługi dodawania nowych produktów, które znają odpowiednie prośby o zapełnienie jego list (np. GET / kategorie, GET / użytkownicy_sprzedaży itp.).

— Dan Lyons
źródło

3

Zakładając, że lista sprzedawców jest względnie statyczna, pomyślałbym, że potrzebujesz osobnego wywołania API, /salesusersktóre możesz wywołać raz (po wczytaniu formularza itp.) I zaoszczędzić, abyś nie musiał ponownie żądać tych danych czas. Pamiętaj, że w REST organizujesz swój interfejs API wokół zasobów, a sprzedawcy są logicznie oddzielni zasoby od produktów.

Podobnie, dzwoniąc /product/new, chciałbyś tylko przesłać dane dotyczące nowego produktu, które mogą zawierać identyfikator użytkownika Sales_user, ale nic więcej. Zmiany w samym user_user byłoby osobnym wywołaniem.

— Dan1701
źródło