Jak radzić sobie z wyjątkami REST?

Jesteśmy w trakcie toczącej się dyskusji o tym, jak radzić sobie z wyjątkami REST.Jak radzić sobie z wyjątkami REST?

Response Rodzaj treści: JSON

dwa rozwiązania mamy:

Wyrzuć wszystkie niezaznaczone wyjątków jako odpowiedź JSON.
Wyślij zapytanie Nieprawidłowy kod odpowiedzi.

Argumenty:

gdy jego błąd, dlaczego powrócić JSON? Po prostu wyślij nieprawidłowy kod odpowiedzi.

Counter Argument:

Kod odpowiedzi są zbyt techniczne do obsługi normalnych deweloperów.

Co powiesz ??

Źródło

2010-06-25 Vanchinathan Chandrasekaran

Zastanawiam się, dlaczego kody odpowiedzi są zbyt techniczne. Jeśli musisz/możesz podjąć jakąkolwiek czynność naprawczą, powinieneś polegać na kodzie odpowiedzi (lub innym kodzie błędu wewnątrz json), a nie na odczytywanych przez użytkownika ciągach błędów. –

Mamy do czynienia z różnymi rodzajami klientów. Nie chcemy więc zakładać, że programiści z klientami są wystarczająco biegli, aby zrozumieć kody odpowiedzi. To też niewiele osób myślało i moje. Jeśli spojrzą na jsona, zrozumieją błąd. –

Jedną z głównych zalet REST jest jednolitość interfejsów. Kiedy mówimy, że mamy aplet REST, klient automatycznie przewiduje listę zasobów i operacji GET PUT POST DELETE i podobnie wie o kodach błędów, które może sobie wyobrazić. Łańcuchy błędów z pewnością będą przydatne dla twojego klienta (programistów) do debugowania. Ale kod, który piszą w swoim api * powinien * podejmować działania oparte na kodach, a nie na łańcuchach. –

Dla interfejsu API JSON, który niedawno opracowałem, robię oba. Zawsze odpowiadam prawidłowym JSON (cóż, zakładam, że w ogóle odpowiadam). Jeśli wykryję nieprawidłowe żądanie, używam statusu 400. Jeśli wykryję błąd serwera (który, jak sądzę, nie jest spowodowany nieprawidłowym żądaniem), używam statusu 5xx. Obiekt JSON zawiera specjalny klucz, który jest ustawiony tylko na błędy, z wartością ciągu.

Myślę, że jest to dobre rozwiązanie, które respektuje zasady REST i może być używane na wiele sposobów. To samo rozwiązanie jest używane przez niektóre inne interfejsy API JSON, takie jak Yahoo Search. Wypróbuj http://search.yahooapis.com/ImageSearchService/V1/imageSearch?appid=YahooDemo&output=json.

Źródło

2010-06-25 21:46:30

+1: Przy RESTENCYNYM wykorzystaniu HTTP musisz bezwzględnie wykorzystać kody odpowiedzi HTTP.Dodatkowe informacje można zwrócić w reprezentacji. –

Właśnie zobaczyłem tę odpowiedź w "Powiązanych" pozycjach SO. I chociaż jest to stara odpowiedź, to oczywiście wciąż się pojawia. Uważam, że obsługa błędów jest o wiele * lepsza niż po prostu używanie kodów stanu HTTP (co jest dobrym początkiem!). Zobacz http://soabits.blogspot.dk/2013/05/error-handling-considerations-and-best.html, aby uzyskać szczegółową dyskusję. –

Używaj kodów błędów jak dla HTTP. Tak więc 50 * za każdy wyjątek powoduje jakiś wewnętrzny problem. I 40 * za złe argumenty. Unikaj używania własnych zdefiniowanych kodów, o ile to możliwe. Chodzi o to, aby mieć "jednolity" interfejs.

Ogólnie. 204 na sukces bez wysyłania zawartości 200 na sukces z reprezentacją json zasobu A jeśli nie powiodła się operacja zwróć odpowiedni kod odpowiedzi. Możesz opcjonalnie zwrócić json. Aby uprościć rzeczy, możesz mieć wspólny format (json) dla wszystkich odpowiedzi na błędy.

http://en.wikipedia.org/wiki/REST to pozycja wymagana przed zamrożeniem specyfikacji aplikacji.

Źródło

2010-06-25 22:07:01

"201 na sukces bez wysyłania żadnych treści." 201 jest tworzony, więc powinien być używany tylko wtedy, gdy "utworzono nowy zasób", a nie dla ogólnego sukcesu. Być może myślisz o 204, "Brak treści" –

oops! dobrze. Dziękuję za poprawienie mnie! –

Jak radzić sobie z wyjątkami REST?

Odpowiedz

Powiązane problemy