Czy interfejs ReST API po cichu ignoruje żądanie zmiany pola nieistniejącego?

Question

Rozważ interfejs API ReST, który zapewnia interfejs do bazy danych.

Czy serwer powinien odpowiedzieć na HTTP 400 Bad Request na żądanie PUT lub PATCH, które próbuje podać nową wartość dla kolumny, która nie istnieje w bazie danych? Czy serwer powinien po cichu zignorować błąd? Czy serwer powinien zrobić coś innego, o czym tu nie wspomniałem?

Answer 1

Jeśli jest to możliwe, że klient, aby ponownie bez dodatkowej wartości należy odpowiedzieć 409. z spec:

10.4.10 409 Konflikt

Żądanie nie mogło być zakończone z powodu konflikt z bieżącym stanem zasobu. Ten kod jest dozwolony tylko w sytuacjach, w których oczekuje się, że użytkownik będzie w stanie rozwiązać konflikt i ponownie zgłosi żądanie. Ciało odpowiedzi powinno zawierać wystarczającą ilość informacji, aby użytkownik mógł rozpoznać źródło konfliktu. Idealnie, jednostka odpowiedzi zawierałaby wystarczającą informację dla użytkownika lub klienta użytkownika, aby rozwiązać problem; może to jednak nie być możliwe i nie jest wymagane.

Konflikty najprawdopodobniej wystąpią w odpowiedzi na żądanie PUT. W przypadku przykładu , jeśli używana była wersja, a podmiot oznaczony PUT zawierał zmiany zasobu, który jest niezgodny z żądaniem wcześniejszego żądania (strony trzeciej), serwer może użyć odpowiedzi 409 , aby wskazać, że może ". t uzupełnić wniosek. W takim przypadku jednostka odpowiedzi o numerze prawdopodobnie zawierałaby listę różnic między wersjami w formacie zdefiniowanym przez typ zawartości odpowiedzi.

Answer 2

Nie cichu ignorować żądania
Nie jestem pewien, jak mogłeś tak, oprócz serwera zamknięcie połączenia bez wysłania odpowiedzi.

400 jest dobry, podobnie jak 409. Możesz także rozważyć 403 Zabronione: serwer zrozumiał twoją prośbę, ale odmawia jej spełnienia.

400 jest zwykle dla nieprawidłowo sformułowanych żądań.
403 sprawdza się, gdy żądanie było wystarczająco dobrze sformułowane, aby kod serwera mógł go przeanalizować i zrozumieć, do czego służy żądanie. Myślę, że najbardziej odpowiada ci tutaj twoje wymagania.

Jednak linia w swoim pytaniu mnie martwi:

próby, aby określić nową wartość dla kolumny, która nie istnieje w bazie danych

Wnioski nie powinny być zmodyfikowanie wartości kolumn w bazie danych. Powinny one modyfikować zawartość zasobu. Te dwie nie są takie same. Łatwo wpaść w pułapkę myślenia "och, po prostu ujawnijmy ten obiekt domeny jako źródło HTTP", ale może to spowodować problemy z skalowalnością w dół. Ogólnie rzecz biorąc, powinieneś mieć więcej zasobów w przestrzeni URI niż obiekty modelu. Pozwala to na przechowywanie w pamięci podręcznej dość statycznych części modelu z inną polityką niż te znacznie bardziej dynamiczne części.

Na przykład w systemie przetwarzania zamówień adres dostawy zmienia się bardzo rzadko, ale śledzenie postępów może się zmieniać co kilka minut. Podaj dwa różne dane URI i różne zasady dotyczące pamięci podręcznej.

Answer 3

Cicho ignorowanie błędów jest receptą na utrudnianie pracy interfejsu API. O ile nie dostarczysz niezłej dokumentacji (a czasami nawet wtedy), programista pracujący nad klientem dla twojego interfejsu API prawdopodobnie nie będzie wiedział, że część jego żądania może zostać zignorowana. W związku z tym najprawdopodobniej nie będą wiedzieć, dlaczego dany zasób nie odzwierciedla tego, co się ostatnio działo. Marnowanie czasu w taki sposób prawdopodobnie nie zwiększy popularności Twojego API.

Answer 4

Z mojego doświadczenia nie należy po cichu ignorować dodatkowych właściwości i traktować PUT/POST tak, jakby nie istniały. Rozważ konsumenta wywołującego interfejs API z opcjonalnymi właściwościami w modelu. Jeśli konsument API ma literówkę w nazwie właściwości opcjonalnej, interfejs API odpowie wartością 200, a konsument będzie potrzebował znacznie więcej czasu na debugowanie niż w przypadku zwrócenia 400. Często najbardziej frustrujące błędy powstają z niewinnych literówek, takich jak "laed" zamiast "lead".