Poziomy uprawnień użytkownika w interfejsie API RESTful

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

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:

• Nie zapomnij o 429 Zbyt wielu żądaniach .
• Nie zapomnij o nagłówku odpowiedzi WWW-Authenticate .

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.