Ostrzeżenia w interfejsie API REST jako błędy niekrytyczne

9

Mam interfejs API REST, który dla niektórych entpoinds, takich jak DELETE, POST lub PUT, mam pewne reguły sprawdzania poprawności, które mogą zwrócić błąd.

Teraz potrzebuję nowego typu błędu, takiego jak błąd niekrytyczny, który powinien zawieść w normalny sposób, ale powinien podjąć działanie, jeśli wysyłane są flagi „ostrzeżenia o wyłączeniu”. Taki użytkownik może zostać zapytany: „Czy na pewno chcesz zmienić ten status, jeszcze nie skończyłeś”

Pytanie : czy istnieje najlepsza praktyka w przypadku tego rodzaju błędów?

Wtórne pytania :

Czy istnieje jakikolwiek semantyczny protokół HTTP dla takiego zachowania, z którego mogę korzystać?
czy nadal podążam za ideą REST (dla mnie wygląda na to, że tak robię) - utrzymuję ją bezstanową

rest api

— użytkownik237329
źródło

Jak decydujesz, czy wyświetlać takie ostrzeżenie użytkownikowi? Wywołujesz punkt końcowy interfejsu API, aby sprawdzić status aplikacji, a następnie wyświetlasz użytkownikowi takie okno dialogowe, blokując interfejs użytkownika, dopóki użytkownik nie odpowie. Następnie wykonasz połączenie. Powinieneś modelować to również za pomocą interfejsu API REST: dodaj punkt końcowy, aby sprawdzić, czy można zapisać, aby wykonać określone zadania. W ten sposób każdy użytkownik interfejsu API może przeprowadzać kontrole „przed lotem”, a nawet przekazać użytkownikowi decyzję. Podejście do kodu stanu HTTP przypomina rm /file„ostrzeżenie”, że plik jest czytany tylko podczas jego usuwania.

— try-catch-wreszcie

Dzieje się tak, gdy biznes nakłada się na kod stanu protokołu. Tak czy inaczej. Czy próbowałeś użyć własnego kodu stanu HTTP? Jeśli Twitter może, ty też. Powiedzmy na przykład 6xx? W każdym razie do tej pory wiem, że możesz dodawać wiadomości do treści odpowiedzi, nawet jeśli jest to 4xx (który zakres byłby zatwierdzony w twoim przypadku).

— Laiv

Wreszcie użyłem 409 CONFLICTodpowiedzi ostrzegawczej. W ten sposób klient jest instruowany, że może wymusić połączenie z tym samym punktem końcowym i tym samym ciałem przy użyciu dodatkowych parametrów „force = 1”

— user237329

4

W http nie ma kodów wyników ostrzegawczych, albo zwracasz sukces (200), albo błąd (400, 500). Jedyne, co wiem o tym, może być analogiczne do tego, czego chcesz, to coś takiego jak kod 401 „nieautoryzowany” - co jest całkowitą awarią, ale powoduje, że większość klientów automatycznie próbuje ponownie nawiązać połączenie z poświadczeniami.

W przypadku interfejsu API REST musisz poinformować serwer o statusie żądania i jak obsłużyć wynik - nie możesz wysłać testu PUT i oczekiwać błędu, jeśli klient nie zostanie ukończony, lub sukcesu, jeśli tak - serwer musi to wiedzieć informacje w celu odesłania właściwego kodu wyniku.

Możesz więc wysłać flagę „ukryj ostrzeżenia” wraz z żądaniem, jeśli nie zostanie ustawiona, serwer zwróci kod błędu 409 (lub podobny), a jeśli zostanie ustawiony, zwróci kod 200 zamiast tego. Użytkownik nie może zostać zapytany „czy chcesz zmienić ten status” po wysłaniu zmiany statusu.

Możesz złożyć wniosek do serwera, aby zapytać, czy użytkownik może oczywiście zmienić status, a następnie wysłać odpowiednią prośbę.

— gbjbaanb
źródło

W żaden sposób nie mówię, że jest to słuszne, ale kody 3xx mogą być postrzegane jako kod powiadomienia lub ostrzeżenia, w którym klient może zdecydować się kontynuować. To powiedziawszy, wolę albo wykonać akcję, albo tego nie zrobię, a może zwracam odpowiedź z dodatkowymi informacjami w zwróconym ciele lub w nagłówkach.

— Archimedix

0

Jeśli chcesz zezwolić użytkownikowi na zastąpienie normalnej obsługi błędów, możesz rozważyć zwrócenie statusu 200 SUKCES z dodatkowymi informacjami w rozszerzonych nagłówkach HTTP. Na przykład możesz wrócić

X-APP-STATUS: 422 Unprocessable entity
X-APP-SOURCE: Invalid ID 'fo0'

Dałoby to Twojemu kodowi po stronie klienta informacje niezbędne do ostrzeżenia użytkownika lub samodzielnego podjęcia działań naprawczych.

— TMN
źródło

2

Nigdy nie lubiłem odpowiedzi, które mówią „Pomyślnie mi się nie udało” :-)

— gbjbaanb 14.04.16