Projektowałem aplikację internetową, a potem przestałem myśleć o tym, jak mój interfejs API powinien być zaprojektowany jako usługa internetowa RESTful. Na razie większość moich identyfikatorów URI ma charakter ogólny i może dotyczyć różnych aplikacji internetowych:
GET /logout // destroys session and redirects to /
GET /login // gets the webpage that has the login form
POST /login // authenticates credentials against database and either redirects home with a new session or redirects back to /login
GET /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx
GET /user/xxx // gets and renders current user data in a profile view
POST /user/xxx // updates new information about user
Mam wrażenie, że robię dużo źle po tym, jak poszperałem w SO i Google.
Zaczynając od /logout
, być może, ponieważ tak naprawdę GET
nic nie robię - bardziej odpowiednie może być POST
żądanie /logout
, zniszczenie sesji, a następnie GET
przekierowanie. I czy /logout
termin powinien pozostać?
A co z /login
i /register
. Mogę zmienić /register
się /registration
, ale to nie zmienia zasadniczo jak mój serwis działa - jeśli to ma głębsze problemy.
Teraz zauważam, że nigdy nie udostępniam /user
zasobu. Być może można to jakoś spożytkować. Na przykład weź użytkownika myUser
:
foo.com/user/myUser
lub
foo.com/user
Użytkownik końcowy nie wymaga dodatkowej szczegółowości w identyfikatorze URI. Jednak który z nich jest bardziej atrakcyjny wizualnie?
Zauważyłem tutaj kilka innych pytań dotyczących SO na temat tego biznesu REST, ale naprawdę byłbym wdzięczny za wskazówki dotyczące tego, co tutaj przedstawiłem, jeśli to możliwe.
Dzięki!
AKTUALIZACJA:
Chciałbym również uzyskać opinie na temat:
/user/1
vs
/user/myUserName
źródło
Odpowiedzi:
Jedna rzecz wyróżnia się w szczególności jako niespełniająca REST: użycie żądania GET do wylogowania.
(z http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods )
Jeśli chodzi o wylogowywanie się i przekierowywanie, możesz wysłać wiadomość do swojego identyfikatora URI wylogowania z odpowiedzią 303 przekierowującą na stronę po wylogowaniu.
http://en.wikipedia.org/wiki/Post/Redirect/Get
http://en.wikipedia.org/wiki/HTTP_303
Edytuj, aby rozwiązać problemy związane z projektem adresu URL:
„Jak zaprojektować zasoby?” to dla mnie ważne pytanie; „Jak zaprojektować adresy URL?” należy wziąć pod uwagę w dwóch obszarach:
Adresy URL, które zobaczą użytkownicy, nie powinny być zbyt brzydkie i sensowne, jeśli to możliwe; Jeśli chcesz, aby pliki cookie były wysyłane w żądaniach do niektórych zasobów, ale nie do innych, będziesz chciał uporządkować swoje ścieżki i ścieżki plików cookie.
Jeśli
JRandomUser
chcesz spojrzeć na swój własny profil i chcesz, aby adres URL był ładniejszy niżfoo.com/user/JRandomUser
lubfoo.com/user/(JRandom's numeric user id here)
, możesz utworzyć oddzielny adres URL tylko po to, aby użytkownik mógł przeglądać własne informacje:Wolałbym twierdzić, że ignorancja jest dużo łatwiejsza niż mądrość na ten temat, ale oto kilka rozważań dotyczących projektowania zasobów:
źródło
GET foo.com/profile/
), czy byłoby to częścią, jak sugeruje momo, warstwy prezentacji? Innymi słowy, co dokładnie powinnaGET
zwrócić ta prośba? Strona internetowa czy jakiś JSON?GET
,POST
,PUT
orazDELETE
zasobów. Strona internetowa to po prostu kolejna platforma uzyskująca dostęp do API. Innymi słowy, projekt adresu URL witryny jest zupełnie inny niż projekt RESTful API. Proszę powiedz mi, czy nadal się mylę haha.RESTful może służyć jako wskazówka przy tworzeniu adresów URL, a także możesz tworzyć sesje i zasoby użytkowników :
GET /session/new
pobiera stronę internetową, na której znajduje się formularz logowaniaPOST /session
uwierzytelnia poświadczenia w bazie danychDELETE /session
niszczy sesję i przekierowuje do /GET /users/new
pobiera stronę internetową, na której znajduje się formularz rejestracyjnyPOST /users
zapisuje wprowadzone informacje do bazy danych jako nowy / użytkownik / xxxGET /users/xxx
// pobiera i renderuje aktualne dane użytkownika w widoku profiluPOST /users/xxx
// aktualizuje nowe informacje o użytkownikuMogą to być liczby mnogie lub pojedyncze (nie jestem pewien, który z nich jest poprawny). Zwykle używałem
/users
dla strony indeksu użytkownika (zgodnie z oczekiwaniami) i/sessions
aby zobaczyć, kto jest zalogowany (zgodnie z oczekiwaniami).Użycie nazwy w adresie URL zamiast liczby (
/users/43
vs./users/joe
) jest zwykle powodowane chęcią bycia bardziej przyjaznym dla użytkowników lub wyszukiwarek, a nie wymaganiami technicznymi. Jedno i drugie jest w porządku, ale radzę być konsekwentny.Myślę, że jeśli pójdziesz z rejestracją / logowaniem / wylogowaniem lub
sign(in|up|out)
, nie działa to tak dobrze z spokojną terminologią.źródło
/new
doGET /session/
nie RESTful? Słyszałem, że czasowniki są zazwyczaj lewej do czasowników HTTP (GET
,POST
itp).Sesje nie są RESTful
Tak, wiem. Robi się to zwykle z OAuth, ale tak naprawdę sesje nie są RESTful. Nie powinieneś mieć zasobu / login / logout głównie dlatego, że nie powinieneś mieć sesji.
Jeśli masz zamiar to zrobić, zrób to RESTful. Zasoby to rzeczowniki, a / login i / logout nie są rzeczownikami. Poszedłbym z / sesją. To sprawia, że tworzenie i usuwanie jest bardziej naturalną czynnością.
POST vs. GET dla sesji jest łatwe. Jeśli wysyłasz użytkownika / hasło jako zmienne, użyłbym POST, ponieważ nie chcę, aby hasło było wysyłane jako część URI. Pojawi się w dziennikach i prawdopodobnie zostanie odsłonięty przez drut. Istnieje również ryzyko, że oprogramowanie ulegnie awarii w przypadku ograniczeń GET argumentów.
Zwykle używam uwierzytelniania podstawowego lub bez uwierzytelniania z usługami REST.
Tworzenie użytkowników
To jeden zasób, więc nie powinieneś potrzebować / rejestrować.
Jakiego rodzaju identyfikatora użyć, to trudne pytanie. Musisz pomyśleć o wymuszeniu niepowtarzalności, o ponownym wykorzystaniu starych identyfikatorów, które zostały USUNIĘTE. Na przykład nie chcesz używać tych identyfikatorów jako kluczy obcych na zapleczu, jeśli identyfikatory mają zostać przetworzone (jeśli w ogóle to możliwe). Możesz jednak sprawdzić konwersję identyfikatora zewnętrznego / wewnętrznego, aby złagodzić wymagania zaplecza.
źródło
Opowiem po prostu z mojego doświadczenia w integracji różnych usług REST Web Services dla moich klientów, niezależnie od tego, czy są one używane do aplikacji mobilnych, czy do komunikacji serwer-serwer, a także budowania REST API dla innych. Oto kilka obserwacji, które zebrałem z REST API innych ludzi, a także z tych, które sami zbudowaliśmy:
Ponieważ usługi REST są zaprojektowane jako usługi, funkcje takie jak logowanie i wylogowanie zwykle zwracają wynik sukcesu / niepowodzenia (zwykle w formacie danych JSON lub XML), który następnie zinterpretowałby konsument. Taka interpretacja może obejmować przekierowanie do odpowiedniej strony internetowej, jak wspomniałeś
Oto kilka punktów z tego, z czym miałem do czynienia. Mam nadzieję, że dostarczy ci pewnych informacji.
Jeśli chodzi o implementację twojego REST, są to typowe implementacje, z którymi się spotkałem:
Wyloguj się z zaplecza i zwróć kod JSON w celu oznaczenia sukcesu / niepowodzenia operacji
Prześlij dane logowania do zaplecza. Zwróć sukces / porażkę. Jeśli się powiedzie, zwykle zwróci token sesji, a także informacje o profilu.
Prześlij rejestrację do zaplecza. Zwróć sukces / porażkę. Jeśli się powiedzie, zwykle traktowane tak samo, jak udane logowanie lub możesz wybrać rejestrację jako odrębną usługę
Pobierz profil użytkownika i zwróć format danych JSON dla profilu użytkownika
Opublikuj zaktualizowane informacje profilowe w formacie JSON i zaktualizuj informacje w zapleczu. Zwróć powodzenie / niepowodzenie dzwoniącemu
źródło
Uważam, że jest to podejście RESTful do uwierzytelniania. Do logowania używasz
HttpPut
. Ta metoda HTTP może być używana do tworzenia, gdy dostarczony jest klucz, a powtarzane wywołania są idempotentne. W przypadku LogOff należy określić tę samą ścieżkę w ramachHttpDelete
metody. Nie użyto czasowników. Prawidłowa liczba mnoga kolekcji. Metody HTTP wspierają ten cel.Jeśli chcesz, możesz zastąpić prąd aktywny.
źródło
Zalecałbym użycie adresu URL konta użytkownika podobnego do Twittera, gdzie adres URL konta użytkownika byłby podobny do tego,
foo.com/myUserName
jak można dostać się na moje konto na Twitterze za pomocą adresu URL adresem https://twitter.com/joelbylerNie zgadzam się z wylogowaniem wymagającym POST. W ramach swojego API, jeśli zamierzasz utrzymywać sesję, identyfikator sesji w postaci UUID może być czymś, co można wykorzystać do śledzenia użytkownika i potwierdzenia, że podejmowane działanie jest autoryzowane. Wtedy nawet GET może przekazać identyfikator sesji do zasobu.
Krótko mówiąc, radzę zachować prostotę, adresy URL powinny być krótkie i łatwe do zapamiętania.
źródło