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
null
wartoś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
źródło
Odpowiedzi:
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.
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:
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.
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:
źródło
UserRole = level1
lub 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.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:
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.
źródło