Tworzę REST API do tworzenia użytkowników, które wymusza unikalne adresy e-mail:Który kod odpowiedzi HTTP dla "Ten adres e-mail jest już zarejestrowany"?
Udane POST /users: HTTP 201 Created
Gdybym znowu POST ten sam adres e-mail, co powinno być kod odpowiedzi? Czy odpowiedni kod odpowiedzi to 409 Conflict?
Tak, 409 jest najwłaściwszym kod odpowiedzi tutaj. Nawet jeśli najprawdopodobniej powrócisz po powodzeniu 201, nadal będziesz wysyłany do zasobu opisanego jako kolekcja, a POSTing duplikatu wiadomości e-mail jest zdecydowanie konfliktem z "bieżącym stanem zasobów" jako zbiorem. Powinieneś zwrócić ciało odpowiedzi zawierające opis problemu i hiperłącza, aby pomóc w rozwiązaniu problemu.
Dzięki za potwierdzenie mojego przeczucia z wyjaśnieniem! Nie myślałem o części hiperłączy, na pewno wymyślę dobry sposób, aby to uwzględnić. – thatmarvin
Często używać (rozszerzenie WebDAV) HTTP 422Unprocessable Entity:
Wniosek został dobrze uformowany, ale nie był w stanie być stosowane ze względu na błędy semantyczne
Ta część sprawia, że myślę, że 422 jest niewłaściwe: "... ale nie udało się przetworzyć zawartych instrukcji". Tutaj nie ma dwuznaczności co do semantyki instrukcji - serwer zrozumiał prośbę, po prostu jej nie spełni.(Plus wolę używać kodów RFC 2616, jeśli mogę pomóc) – thatmarvin
Chociaż zaakceptowana odpowiedź jest poprawna w wyświetlaniu prawidłowego kodu statusu dla zadania, chcę dodać, że wprowadzasz lukę w zabezpieczeniach.
Jeśli zwrócisz 409 w celu rejestracji konta, ujawniasz usługę do wyliczenia konta.
Zależnie od aplikacji, jeśli api jest publiczne lub nie, itp., Możesz zwrócić 201, nawet jeśli konto nie zostało utworzone.
Odpowiedzieć +1 na Barts - ze względów bezpieczeństwa. Zwykle zgadzam się, że 409 to dobry kod statusu dla czegoś. to już istnieje. Ale w środowisku kont użytkowników/uwierzytelniania/autoryzacji itp. Nie ujawniałbym istniejących kont użytkowników w bazie danych.
Oczywiście istnieją inne mechanizmy zabezpieczenia w tym miejscu. Jeśli nie masz nic przeciwko wyeksponowaniu niewielkiej liczby kont, możesz dodać zachowanie do aplikacji, które zwraca 401 lub 403 na wielu 409 zdarzeniach z jednego adresu IP.
Inną opcją (ogólnie) jest samodzielne zdefiniowanie kodu statusu, aby mieć 2xx, który różni się od istniejących standardowych wariantów 2xx. Może to być opcja, jeśli nie chcesz obsłużyć "już istnieje" jako błędu. Byłoby to jednak postrzegane jako niestandardowe i miałoby taki sam niebezpieczny charakter jak 409 w twoim konkretnym przykładzie.
Nie sądzę, że to dobry pomysł. Jeśli połączenie jest nawiązywane za pośrednictwem proxy, wyniki mogą być nieprzewidywalne. – Cheery
Myślę, że to dobry pomysł! Ponieważ HTTP ma kod statusu, więc używaj ich! Jest także bardzo przydatny, gdy trzeba później debugować i mieć tylko pliki dostępu lub inne pliki dziennika, ale jeśli istnieje kod HTTP ... :) – powtac
'409 - Konflikt' jest bardzo dobrym wyborem dla tego rodzaju reakcji. –