Różne zasoby zasobów REST oparte na uprawnieniach przeglądania użytkownika

Question

Chcę podać różne odpowiedzi na to samo pytanie dla różnych użytkowników, w oparciu o prawa dostępu. Czytam to pytanie:

Excluding private data in RESTful response

Ale nie zgadzam się z przyjętą odpowiedzi, w którym stwierdza, że ​​należy zapewnić zarówno /people.xml i /unauthenticated/people.xml, gdyż moje rozumienie reszta jest, że dany zasób powinien mieszkać w konkretna lokalizacja, a nie kilka zależnie od tego, ile informacji Cię interesuje.

System, który tworzę, jest jeszcze bardziej skomplikowany niż ten. Załóżmy, że użytkownik utworzył wiele kręgów znajomych i przypisał im różne prawa dostępu. Na przykład moje "znajomi" mogą mieć dostęp do moich urodzin, a moje "zawodowe" koło może mieć dostęp do mojej historii zatrudnienia, ale nie na odwrót. Aby zastosować odpowiedź z podanego przeze mnie pytania, muszę mieć sposób na uzyskanie wszystkich kręgów użytkownika (które być może będę chciał zachować w tajemnicy ze względów bezpieczeństwa), a następnie przejść przez /circles/a/users/42, /circles/b/users/42, /circles/c/users/42 itd. , a następnie połączyć wyniki, aby wyświetlić maksymalną ilość dostępnych informacji. Oczywiście nie ma potrzeby, aby jedno koło otrzymywało wszystkie informacje, które otrzymają inne kręgi. Wierzę, że jest to wystarczająco trudne (zauważ, że prawdopodobnie muszę to zrobić z kilkoma rodzajami obiektów i że przyszłe wersje mogą wymagać innej procedury), ale co jeśli chcę nałożyć ograniczenia bezpieczeństwa na konkretnego użytkownika pomimo faktu, że że jest także w niektórych kręgach? Czy ten problem może zostać rozwiązany? Nawet jeśli odmówię odpowiedzi na którekolwiek z powyższych zapytań i wymyślę nowe, które może dać mi odpowiedź, to nadal ujawni to, że ten konkretny użytkownik jest traktowany inaczej z powodu indywidualnych ograniczeń dostępu.

Czego mi tu brakuje? Czy jest nawet możliwe rozwinięcie usługi internetowej RESTful?

Jeśli wniosek jest taki, że zachowanie nie jest restupowane, czy nadal stanowiłoby to sytuację, w której byłoby moralnie w porządku, aby zerwać umowę REST? Jeśli tak, jakie są negatywne konsekwencje? Czy na przykład ryzykuję problemami z buforowaniem proxy?

Answer 1

Zgadzam się, że inne rozwiązanie nie wydaje się właściwe. Powoduje to, że struktura adresu URL jest skomplikowana i trudniej jest znaleźć zasób. Jeśli jednak zrobiłeś to poprawnie, nie powinno mieć znaczenia adres URL zasobu, który kontroluje serwer (i można go dowolnie przesuwać). Jeśli twój klient naprawdę jest "REST", odkryłby potrzebne zasoby poprzez wcześniejsze negocjacje z serwerem. Tak więc ścieżka naprawdę nie ma znaczenia dla klienta. Nie podoba mi się to, ponieważ jest mylące w użyciu - nie z powodu jakiegoś naruszenia zasad REST.

Ale to prawdopodobnie nie odpowiada na twoje pytanie - To, czego nie wspomniałeś, to twoja konfiguracja zabezpieczeń - prawdopodobnie masz do przekazania token sesji z żądaniem jako część nagłówka żądania. Tak więc przetwarzanie back-end powinno mieć możliwość powiązania go z określonym zestawem ograniczeń bezpieczeństwa. Stamtąd utworzysz listę z dowolną logiką biznesową, której potrzebujesz i zwrócisz ograniczony zasób w oparciu o bezpieczeństwo użytkownika związane z sesją.

Dla samego algorytmu zwykle stosuje się algorytm typu najmniejszy lub najbardziej restrykcyjny, który łączy dopuszczalne dane w odpowiedzi (bardzo podobne do rzeczywistych java lub modelu bezpieczeństwa użytkownika Microsoft).

Jeśli dane mają inną strukturę niż w przypadku ograniczonej/nieobjętej ograniczeniami, można utworzyć dwie różne reprezentacje danych i zwrócić je każdemu użytkownikowi, do którego użytkownik miał uprawnienia. Klient powinien mimo wszystko pytać o akceptowalne typy odpowiedzi na mime, a po prostu poda różne odpowiedzi na podstawie bezpieczeństwa sesji w nagłówku żądania. Alternatywnie możesz podać opcjonalne elementy z reprezentacjami i wypełnić odpowiednią jedną bazę z autoryzacją (chociaż jest to w moim mniemaniu trochę hack-ee).

Answer 2

Według dysertacji Fielding (to naprawdę jest wielki pisanie):

Zasób jest koncepcyjnym mapowanie do zbioru jednostek, a nie podmiot, który odpowiada odwzorowaniu w danym momencie.

Innymi słowy, jeśli masz zasób, który jest definiowany jako „przypisanych projektów użytkownik żądający” oraz reprezentacji jego dostępne przez URI /projects, nie narusza żadnych ograniczeń odpoczynku wracając jedną listę projektów (tj. reprezentacja) dla użytkownika A i innego (reprezentacja) dla użytkownika B, gdy uzyskują ten sam identyfikator URI. W ten sposób interfejs jest jednolity/spójny.

Poza tym, REST przewiduje jedynie, że wyraźna instrukcja buforowanie być dołączone do odpowiedzi, czy to jest „cache tak długo” lub „nie buforować w ogóle”:

ograniczenia Cache wymagają dane w odpowiedzi na żądanie mogą być domyślnie lub jawnie oznaczone jako buforowane lub niecacheable.

Wybór sposobu zarządzania zależy od Ciebie.

Mając to na uwadze,

Powinieneś czuć się komfortowo zwracając reprezentację zasobu że zmienia się w zależności od użytkownika z prośbą o przedstawienie konkretnego zasobu, o ile nie naruszają ograniczeń jednolitego interfejsu - nie używaj pojedynczego identyfikatora zasobu do zwracania reprezentacji różnych zasobów.

Jeśli to pomaga, należy wziąć pod uwagę, że serwer odpowiada również za pomocą różnych reprezentacji zasobu - XML ​​lub JSON, francuski lub angielski itd. Dane uwierzytelniające wysyłane wraz z żądaniem są po prostu kolejnym czynnikiem, z którego serwer może korzystać. określanie, którą reprezentację wysłać w odpowiedzi. Po to jest sekcja nagłówka.