Níveis de permissões de usuário em uma API RESTful

Digamos que eu tenha uma empresa que classifique os gatos mais fofos da internet.

Ofereço um recurso no/cats/ qual fornece aos usuários os mais recentes e adoráveis ​​gatos adoráveis.

Os usuários podem obter apenas os três principais gatos se não tiverem pago ou se registrado. Os 10 melhores gatos se pagaram 337 dólares e estão conectados, e os 100 melhores gatos se pagaram 1337 dólares e estão conectados. Eu tenho um 'identificador de usuário' ao fazer a solicitação.

Em resumo, os consumidores /cats/obtêm um número diferente de gatos com base em sua "classificação de usuários" . Eu tenho um identificador de usuário no consumidor final, mas não tenho representação explícita do nível do usuário no consumidor final. Gostaria de informar aos usuários que eles podem atualizar sua assinatura ao fazer a solicitação. Ou seja, preciso distinguir entre três gatos, pois ofereço apenas três e três, porque é isso que o nível de usuário permite .

Qual é a melhor prática para distinguir a limitação do recurso porque o consumidor não possui privilégios suficientes e limitá-lo porque é isso que o consumidor possui?

Como o cliente sabe se pode atualizar sua classificação? Ou seja, eles só tem um recurso limitado, porque eles não tem permissões. Qual é a melhor prática aqui?

Observe que essa é uma simplificação grosseira do caso real. Além disso, apenas para esclarecer - a leitura é apreciada.

Atualizar:

Aqui estão as opções que consideramos:

• Armazenando os objetos de permissão do usuário uma vez no cliente, consultando-o apenas quando o login ou atualização da conta é realizado.
• Passando nullvalores em JSON indicando que ele existe, mas nada real foi transferido. Portanto, 10 gatos para um usuário com 3 gatos podem ser["Garfield","Sylvester","Puss in Boots",null*7]
• Passando um Par de Permissões de Recursos {cats:["Whiskers","Fluffy","Socks"],authCount:3}

Eu gostaria de fazer isso da primeira vez para entregar os gatos mais fofos da melhor maneira possível e gostaríamos e gostaríamos

Eu diria que depende do seu público.

No-dev

Se o seu público não é um desenvolvedor, eu iria da seguinte maneira:

Digamos que você retorne o JSON por causa do exemplo.

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!"
    }
}

Ou algo parecido.

É informativo para o usuário saber qual é o status de sua conta e permite que você coloque as informações que desejar, como uma mensagem de marketing. O ponto mais importante dessa maneira é oferecer visibilidade fácil aos usuários da conta atual deles.

Dev

No entanto, se o seu público for puramente desenvolvedor, eu diria: siga o caminho completo compatível com HTTP. Para armazenar os metadados, use os cabeçalhos HTTP.

Aqui está um exemplo:

GET /cats HTTP/1.1

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

Em seguida, forneça uma documentação clara do significado desses cabeçalhos. A maioria dos desenvolvedores procura diretamente a documentação quando vê esses cabeçalhos personalizados, especialmente se estiver vendo um limite. Você pode ir ainda mais longe e mostrar o link nos cabeçalhos. Ou você pode mostrar um link para a página de preços.

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

Mas, novamente, muitos desenvolvedores não sabem como o HTTP funciona.

Então é sua decisão

Um é mais correto, o outro é mais acessível.

Diversos

Algumas outras coisas relacionadas à sua pergunta:

• Não se esqueça de 429 Demasiados pedidos .
• Não se esqueça do cabeçalho de resposta WWW-Authenticate .

Como o cliente sabe se pode atualizar sua classificação?

Isso depende do cliente. Normalmente, você pode colocar essas informações na forma de uma mensagem de hipertexto (também conhecida como HTML) no corpo da resposta do método REST. No entanto, isso só faz sentido se a API REST for usada com um cliente HTML.

Semelhante para XML e JSON.

Editar: você pode confundir o uso de uma API (expanda esse acrônimo) com o marketing de seus tipos de conta / planos de usuário. Eu não misturaria isso, pois sempre fica duvidoso (as decisões de negócios podem exigir mudanças mais rápidas do que as mudanças no software para comunicar respostas diferentes, pois essas mudanças podem entrar no prato a tempo).

Em vez disso, informe seus usuários por um canal diferente, por exemplo, com o boletim informativo quais são seus benefícios.

Isso funciona particularmente bem quando a pessoa que se inscreve no serviço não é quem está programando na API. Por exemplo:

George (que é um rapaz orgulhosamente gay com 36 anos de idade) adora acesso a cute-cats-4-me.com e diz a seu cônjuge de 16 anos (que gosta de scripts para sistemas de computador, incluindo linux) para criar um aplicativo de sinalização digital exibindo belos gatinhos na parede do apartamento.

Então, o cara que está se divertindo programando isso, na verdade, não é o destinatário mais direto das informações.

Como alternativa, em resposta ao login e a um método de informações do usuário, forneça todos os detalhes sangrentos.

Porém, quando um usuário solicita gatos de forma programática, ele já deve estar ciente de por que só recupera três gatos ou mais. Mas você não resolve esse problema de comunicação com o código.

Caso contrário, permita que eles consultem mais e, em seguida, retornem um aviso de falha se seus direitos não forem suficientes. Mas, novamente, esse não é um software fácil de usar.