Gdy użytkownik zarejestruje się w mojej aplikacji internetowej, wyślę wiadomość e-mail, aby zweryfikować jego skrzynkę odbiorczą. W e-mailu jest link do zasobu tak:Jaki jest sposób REST na weryfikację wiadomości e-mail?
GET /verify/{token}
Od zasobu jest aktualizowana za kulisami, prawda przełamać relaksującego podejście?
Jak mogę to zrobić w trybie RESTOWNOWYM?
Czy nie zastanawiasz się nad REST? Po weryfikacji e-mailem użytkownik ma po prostu kliknąć link z dowolnego agenta użytkownika poczty, z którego korzysta, więc otrzymasz prosty GET na serwerze (przedstawiony jako hiperłącze do użytkownika) z token w ścieżce lub jako część ciągu zapytania:
GET http://example.com/verify-email/TOKEN
GET http://example.com/verify-email?token=TOKEN
Wszystko jest w porządku w tym przypadku użycia. Nie jest to tak naprawdę zasób, który dostajesz lub tworzysz; tylko wyzwalacz dla jakiegoś procesu na zapleczu.
Jak myślisz, dlaczego miałoby to źle wyglądać?
Myślę, że byłby to dobry projekt, ponieważ w RESTU URI nie powinien być czasownikiem (sprawdź w tym przypadku). – user3482682
To zależy od tego, co próbujesz zrobić.
Czy uruchamia się wiadomość e-mail po sprawdzeniu użytkownika na przykład? Jeśli tak, to nie jest to metoda idempotentna i powinieneś używać POST.
Przykład:
POST /users/{id}/verify/{token}
Jeśli metoda nie ma żadnych konsekwencji oprócz aktualizacji, myślę, że należy użyć PUT.
Jeśli intencją jest, że użytkownik może kliknąć hiperłącze w otrzymanym e-mailu, POST i PUT nie są możliwe, dopóki nie zaczniesz dołączać tagów formularza; która nie zadziała, jeśli użytkownik wyświetli wiadomość e-mail jako zwykły tekst. – JeroenHoek
Wszelka komunikacja między REST API i tego rodzaju integracją będzie wymagać strony internetowej do interakcji. Hiperłącze do wiadomości e-mail wymagałoby wysłania użytkownika do witryny, a nie interfejsu API. Witryna otrzyma GET/something? Token = blabla i wyśle ją do REST API –
To, o czym mówisz, to NIE REST. REST służy do komunikacji między maszyną a maszyną, a nie do komunikacji między ludźmi. Możesz opracować klienta REST klienta, który wysyła aktywację do usługi REST.
można używać weryfikacji URI w przeglądarce, aby uzyskać dostęp do klienta, rekreacyjne:
# user follows a hyperlink in the browser manually
GET example.com/client/v1/verify/{token}
# asking the client to verify the token
a potem klient REST dostanie hiperłącze do weryfikacji z usługi REST i wysłać pocztą do służby w tło.
# the REST client follows the hyperlinks given by the service automatically
# the REST client can run either on the HTTP client or server side
GET example.com/api/v1
# getting the starting page of the REST service
# getting the hyperlink for verification
POST example.com/api/v1/verification {token}
# following the verification hyperlink
Jeśli masz stronie serwera klienta 1st Party spoczynku, wówczas żądania HTTP do usługi REST będzie całkowicie uruchamiane na serwerze i nie będzie widać nic na ten temat w przeglądarce. Jeśli masz klienta REST po stronie klienta, możesz wysłać POST w przeglądarce za pomocą AJAX CORS lub możesz spróbować POST bezpośrednio za pomocą formularza HTML (niezalecane). W każdym razie aktywacja powinna być POST lub PUT.
Zgadzam się z Tobą, że aktywacja powinna być POST lub PUT. Ale w mojej niedoświadczonej opinii myślę, że w RESTU URI nie powinien być czasownikiem (w tym przypadku weryfikacja), ale z drugiej strony nie istnieje ŻĄDANE żądanie HTTP. – user3482682
@ user3482682 Tylko identyfikator URI klienta zawiera czasownik "verify". Identyfikator URI usługi zawiera "weryfikację", która jest rzeczownikiem. Twoim głównym problemem jest to, że mylisz przeglądarkę z klientem REST. Przeglądarka nie jest klientem REST, jest tylko klientem HTTP. – inf3rno
Dziękuję inf3rno za porady, uznałem twoją odpowiedź za użyteczną. – user3482682
Nie dodaje niczego za kulisami? Dasz im formularz do opublikowania, aby go zmienić? To będzie post i zaktualizuj hasło, token pozwoli im poprawnie zobaczyć formularz. –
Za kulisami przeszukuję DB, który użytkownik ma ten token i ustawia pole na NULL, biorąc pod uwagę ważność emaila tego użytkownika. – user3482682
Po prostu weź do formularza (nie dotykaj DB), a następnie opublikuj do siebie i użyj polecenia get param + get param i opublikuj go w DB, a następnie zaktualizuj. Jeśli użytkownik trafi w adres URL, nie chcesz, aby nie mógł go ponownie uderzyć, jeśli zechce wracać, by uderzyć na pewno? –