Zastanawiam się, w jakim stopniu ludzie utrzymują swoje aplikacje w stanie RESTful. Wydaje mi się, że wszystko się psuje bardzo łatwo, w którym to momencie muszę zrobić to, co powiedział mi kiedyś starszy programista, gdy byłem nowy w mojej karierze i przejąłem całą filozofię-architektonię: „Po prostu napisz ten cholerny kod”.

Konkretny przykład, implementuję niestandardowe uwierzytelnianie w aplikacji Rails i mam standardowy formularz "Przypomnienie hasła". To, co zamierzamy zrobić na końcu procesu z punktu widzenia REST, to PUT na obiekcie użytkownika, ponieważ aktualizujemy obiekt użytkownika. Ale nawet ignorując, że istnieje wiele sposobów na zaktualizowanie użytkownika (por. Jak to zrobić Aktualizacje zgodne z REST?), na początku nie wiemy, jakiego użytkownika aktualizujemy, a na koniec wyślemy potwierdzenie e-mailem i klikniemy link zwrotny za pomocą identyfikatora użytkownika + bezpieczny klucz. Więc teraz rzeczą, która w końcu uruchamia aktualizację na użytkowniku, jest prosty link (o zgrozo!) — w przeciwnym razie muszę zdenerwować mojego użytkownika innym przyciskiem, aby był RESTful.

To tylko jeden z przykładów, które skłoniły mnie do pytania, ale wydaje mi się, że w każdej niebanalnej aplikacji na pewno będzie ich kilkadziesiąt.

Czy więc ludzie w zasadzie używają architektury RESTful jako ogólnej wytycznej, którą sprytni programiści ignorują w razie potrzeby? Wrażenie, jakie odnoszę z literatury, jest zupełnie inne od tego - stąd pytanie, jak poradziłeś sobie z wyjątkami. Dziękuję.

(Właściwie przychodzi mi do głowy, że ostatecznym wynikiem w tym przypadku byłaby inna forma z nowym hasłem/potwierdzeniem, której celem może być PUT, ale moje ogólne poczucie, że jest to czasem nieporęczne, nadal mam. Może to moje własna powolność - nie będzie to pierwszy raz).

2
John Lockwood 30 sierpień 2012, 00:18

2 odpowiedzi

Najlepsza odpowiedź

Tam, gdzie pracuję, postanowiliśmy starać się być jak najbardziej RESTful, ale będziemy też pragmatyczni i jeśli coś nie pasuje do wytycznych REST (a wszyscy zaangażowani zgadzają się, że tak jest), będziemy chętni rozejść się. Mówiąc to, myślę, że większość przypadków użycia może być nieco RESTful.

Co powiesz na coś takiego, jeśli nie znasz identyfikatora użytkownika. Zbiór tokenów zmiany hasła z identyfikatorem jako adresem e-mail:

GET /changepasswordtoken/{userEmail}

Lub jeśli klient API zna identyfikator użytkownika, może być ładniej:

GET /user/{userId}/changepasswordtoken

Pytasz o GET token zmiany hasła dla użytkownika. Jeśli jest to publiczny interfejs API, to oczywiście nie zwrócisz tego w ładunku odpowiedzi, ale ładunek może zwrócić komunikat „Zmień hasło wysłane na e-mail” lub coś takiego.

Następnie, aby zaktualizować hasło PUT lub PATCH użytkownika z tokenem zmiany hasła jako parametrem ciągu zapytania.

PUT /user/{userId}?changepasswordtoken=xyz

{
     "password": "new password"
}
1
theon 30 sierpień 2012, 00:43

Z http://www.ics.uci.edu/~ fielding/pubs/dissertation/web_arch_domain.htm#sec_4_4:

REST zapewnia zestaw ograniczeń architektonicznych, które zastosowane jako całość, kładą nacisk na skalowalność interakcji komponentów, ogólność interfejsów, niezależne wdrażanie komponentów i komponentów pośrednich w celu zmniejszenia opóźnień interakcji, wymuszenia bezpieczeństwa i enkapsulacji starszych systemów.

Jeśli zamiast tego potrzebujesz stylu architektonicznego, który kładzie nacisk na zaciemnianie aktorów i zasobów, jednorazową interakcję od punktu do punktu oraz pełne uwzględnienie i ujawnienie starszych systemów (takich jak poczta e-mail w formacie HTML), to nie, nie musisz być RESTful . Znajdź (lub wymyśl) styl architektoniczny, który odpowiada Twoim kryteriom. W REST nie ma nic magicznego; jest to zestaw ograniczeń, który działa w wielu obszarach problemowych, ponieważ został zaprojektowany i spełnia ich potrzeby. Jeśli masz różne potrzeby, stosowanie tych samych ograniczeń przyniosłoby efekt przeciwny do zamierzonego i byłoby głupie.

0
fumanchu 30 sierpień 2012, 16:06