Poziomy uprawnień użytkownika w interfejsie API RESTful

23

Załóżmy, że mam firmę, która klasyfikuje najładniejsze koty w Internecie.

Oferuję źródło, w/cats/ którym zapewnia użytkownikom najnowsze, najładniejsze urocze koty.

Użytkownicy mogą dostać tylko 3 najlepsze koty, jeśli w ogóle nie zapłacili lub się zarejestrowali. 10 najlepszych kotów, jeśli zapłaciło 337 dolarów i jest zalogowanych, a 100 najlepszych kotów, jeśli zapłaciło 1337 dolarów i było zalogowanych. Mam „identyfikator użytkownika” podczas wysyłania żądania.

Krótko mówiąc, konsumenci /cats/otrzymują inną liczbę kotów na podstawie ich „rankingu użytkowników” . Mam identyfikator użytkownika po stronie konsumującej, ale nie mam wyraźnej reprezentacji poziomu użytkownika po stronie konsumującej. Chciałbym poinformować użytkowników, że mogą zaktualizować subskrypcję podczas wysyłania żądania. Oznacza to, że muszę rozróżniać 3 koty, ponieważ oferuję tylko 3 koty i 3 koty, ponieważ dopuszcza to poziom użytkownika .

Jaka jest najlepsza praktyka w rozróżnianiu ograniczania zasobów, ponieważ konsument nie ma wystarczających przywilejów i ograniczania go, ponieważ to właśnie ma konsument?

Skąd klient wie, czy może ulepszyć swój ranking? Oznacza to, że dostał tylko ograniczony zasób, ponieważ oni nie mają uprawnień. Jaka jest tutaj najlepsza praktyka?

Uwaga: jest to rażące uproszczenie rzeczywistej sprawy. Również dla wyjaśnienia - czytanie jest mile widziane.


Aktualizacja:

Oto opcje, które rozważaliśmy:

  • Przechowywanie obiektów uprawnień użytkownika jeden raz na kliencie, zapytanie o nie tylko przy logowaniu lub aktualizacji konta.
  • Przekazywanie nullwartości w JSON wskazujące, że istnieje, ale faktyczne nic nie zostało przeniesione. Może to być 10 kotów dla użytkownika z 3 kotami["Garfield","Sylvester","Puss in Boots",null*7]
  • Przekazywanie pary uprawnień do zasobów {cats:["Whiskers","Fluffy","Socks"],authCount:3}

Chciałbym to zrobić po raz pierwszy, aby dostarczyć najładniejsze koty w najlepszy możliwy sposób, a my i tak chcielibyśmy

Benjamin Gruenbaum
źródło
4
teraz chcę zobaczyć zdjęcia uroczych kotów
Carrie Kendall
Nie rozumiem Jeśli nigdzie nie przechowujesz „poziomu użytkownika”, nie możesz rozróżnić. Wygląda na to, że nie masz żadnych informacji o użytkowniku na serwerze, więc nie możesz przechowywać na nim poziomu ich użytkowników.
Jan Doggen,
@JanDoggen Mam poziom użytkownika na serwerze (klient przekazuje identyfikator do serwera).
Benjamin Gruenbaum,
Wsparcie? Nie dostaję referencji 1337?
Marjan Venema
Leet
JustinC

Odpowiedzi:

18

Powiedziałbym, że to zależy od twojej publiczności.

Nie, dev

Jeśli twoi odbiorcy nie są programistami, postąpiłbym następująco:

Powiedzmy, że zwracasz JSON dla przykładu.

GET /cats HTTP/1.1

{
    "cats": [
        "Can I haz cheeseburger",
        "If it fits, I sits",
        "It's caturday!"
    ],
    "permissions": {
        "level": "free",
        "information": "You have access to 3 cats. Upgrade to ... to get 10 cats!"
    }
}

Lub coś podobnego.

Jest to pouczające dla użytkownika, aby wiedzieć, jaki jest stan jego konta, i pozwala umieścić dowolne informacje, takie jak komunikat marketingowy. Najważniejszym punktem tego sposobu jest zapewnienie użytkownikom łatwego wglądu w ich rachunek bieżący.

Dev

Jeśli jednak Twoi odbiorcy są programistami, powiedziałbym: idź z pełną zgodnością z HTTP. Do przechowywania metadanych używasz nagłówków HTTP.

Oto przykład:

GET /cats HTTP/1.1

X-Account: anonymous
X-Account-Possible-Upgrades: 2
X-Account-Limit: 3

Następnie przedstaw jasną dokumentację tego, co oznaczają te nagłówki. Większość programistów pójdzie prosto do dokumentacji, gdy zobaczą te niestandardowe nagłówki, zwłaszcza jeśli widzą limit. Możesz pójść jeszcze dalej i pokazać link w nagłówkach. Lub możesz wyświetlić link do strony z cenami.

X-Account-Doc: http://your/doc

Ale z drugiej strony wielu programistów nie wie, jak działa HTTP.

Więc to twój telefon

Jedna jest bardziej poprawna, druga jest bardziej dostępna.

Misc

Kilka innych rzeczy związanych z twoim pytaniem:

Florian Margaine
źródło
1
Tak, ma to absolutny sens, chociaż jako dodatkową notatkę uważam, że niektóre informacje uwierzytelniające (ent / orize) przechodzące w nagłówkach HTTP są odpowiednim podejściem, ponieważ są to skutecznie metadane.
Jimmy Hoffa
@ JimmyHoffa To rzeczywiście metadane, a moją pierwszą myślą było użycie nagłówków HTTP. Jednak w tym przypadku nagłówki HTTP nie zapewniają wystarczającej widoczności dla klienta i szczegółowości wymaganej w przypadku komunikatów marketingowych. (
Edytowałem
@JimmyHoffa jak? 402 nie zrobi w tym przypadku. Co sugerujesz?
Benjamin Gruenbaum
@BenjaminGruenbaum Nie powiedziałem kodów odpowiedzi, powiedziałem nagłówki; możesz dodać wszystkie niestandardowe nagłówki, które chcesz dla metadanych, rozsądnie byłoby mieć wszystkie odpowiedzi z uspokajającego interfejsu API, po prostu mieć rolę użytkowników w nagłówku UserRole = level1lub jakkolwiek chcesz to nazwać, aby upewnić się, że konsumenci zawsze wiedzą, jak to zrobić prezentują otrzymywane dane i są spójne we wszystkich odpowiedziach, w których powracające modele danych będą różne od jednego żądania do drugiego, konsumenci zawsze mogą sprawdzić swoją rolę w ten sam sposób.
Jimmy Hoffa
1
@BenjaminGruenbaum Całkowicie przepisałem odpowiedź.
Florian Margaine
4

Skąd klient wie, czy może ulepszyć swój ranking?

To zależy od klienta. Zwykle można umieścić takie informacje w postaci wiadomości hipertekstowej (znanej również jako HTML) w treści odpowiedzi metody REST. Ma to jednak sens tylko wtedy, gdy interfejs API REST jest używany z klientem HTML.

Podobne dla XML i JSON.


Edycja: Możesz pomylić używanie interfejsu API (rozwinąć ten akronim) z marketingiem typów kont / planów użytkowników. Nie mieszałbym tego, ponieważ zawsze robi się podejrzany (decyzje biznesowe mogą wymagać szybszych zmian niż zmiany w oprogramowaniu w celu komunikowania różnych odpowiedzi, ponieważ zmiany te są w stanie dostać się na talerz).

Zamiast tego powiedz swoim użytkownikom innym kanałem, np. Za pomocą biuletynu, jakie są ich zalety.

Działa to szczególnie dobrze, gdy osoba rejestrująca się w usłudze nie jest tą, która programuje przeciwko API. Na przykład:

George (który jest dumnym gejem w wieku 36 lat i kocha kocięta) kupuje dostęp do cute-cats-4-me.com i mówi swojemu 16-letniemu małżonkowi (który jest dobry w skryptowych systemach komputerowych, w tym Linuksie), aby stworzył Aplikacja Digital Signage wyświetlająca ładne małe koteczki na ścianie w mieszkaniu.

Więc facet, który dobrze się bawi w programowaniu, nie jest tak naprawdę najprostszym adresatem informacji.

Ewentualnie w odpowiedzi na login i metodę informacji o użytkowniku podaj wszystkie krwawe szczegóły.

Ale kiedy użytkownik prosi o koty programowo, powinna już wiedzieć, dlaczego odzyskuje tylko trzy koty lub więcej. Ale nie rozwiązujesz tego problemu z kodem.

W przeciwnym razie pozwól im zapytać więcej, a następnie zwróć powiadomienie o awarii, jeśli ich prawa nie są wystarczające. Ale znowu, to nie jest oprogramowanie przyjazne dla użytkownika.

hakre
źródło
1
@Racheet: Czy masz problem, kiedy dziewczyny mają pieniądze w domu i mówią chłopcom, co mają robić?
hakre
1
Mam problem z przykładem, który twierdzi, że dziewczyny potrzebują chłopaków, aby zrobić dla nich programowanie.
Racheet