Livelli di autorizzazioni utente in un'API RESTful

Diciamo che ho una compagnia che classifica i gatti più teneri su Internet.

Offro una risorsa alla/cats/ quale fornisce agli utenti gli ultimi, adorabili gatti adorabili.

Gli utenti possono ottenere solo i primi 3 gatti se non hanno pagato o registrati. I primi 10 gatti se hanno pagato 337 dollari e sono connessi, e i primi 100 gatti se hanno pagato 1337 dollari e sono connessi. Ho un "identificatore utente" quando faccio la richiesta.

In breve, i consumatori /cats/ottengono un numero diverso di gatti in base alla loro "classifica degli utenti" . Ho un identificatore utente sul lato consumante, ma non ho una rappresentazione esplicita del livello utente sul lato consumante. Vorrei informare gli utenti che possono aggiornare il loro abbonamento al momento della richiesta. Cioè, devo distinguere tra 3 gatti poiché offro solo 3 gatti e 3 gatti perché questo è ciò che il livello utente ha permesso .

Qual è la migliore pratica per distinguere la limitazione della risorsa perché il consumatore non ha sufficienti privilegi e limitarla perché è ciò che ha il consumatore?

Come fa il cliente a sapere se può aggiornare il proprio ranking? Cioè, hanno ottenuto solo una risorsa limitata, perché essi non dispongono di autorizzazioni. Qual è la migliore pratica qui?

Nota, questa è una grossolana semplificazione del caso reale. Inoltre, solo per chiarire: la lettura è apprezzata.

Aggiornare:

Ecco le opzioni che abbiamo considerato:

• Memorizzare gli oggetti delle autorizzazioni utente una volta sul client, eseguendo la query solo quando viene eseguito l'accesso o l'aggiornamento dell'account.
• Passando nullvalori in JSON che indica che esiste, ma non è stato trasferito nulla . Quindi potrebbero essere 10 gatti per un utente con 3 gatti["Garfield","Sylvester","Puss in Boots",null*7]
• Passaggio di una coppia di autorizzazioni per le risorse {cats:["Whiskers","Fluffy","Socks"],authCount:3}

Mi piacerebbe farlo bene la prima volta per consegnare i gatti più teneri nel miglior modo possibile e vorremmo e vorremmo

Direi che dipende dal tuo pubblico.

No-dev

Se il tuo pubblico non è uno sviluppatore, sceglierei il modo seguente:

Supponiamo che tu restituisca JSON per il bene dell'esempio.

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

O qualcosa di simile.

È informativo per l'utente sapere qual è lo stato del suo account e ti consente di inserire qualsiasi informazione tu voglia, come un messaggio di marketing. Il punto più importante di questo modo è quello di dare una certa visibilità agli utenti del loro account corrente.

dev

Tuttavia, se il tuo pubblico è puramente sviluppatori, allora direi: vai con il modo completo di conformità HTTP. Per memorizzare i metadati, utilizzare le intestazioni HTTP.

Ecco un esempio:

GET /cats HTTP/1.1

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

Quindi, fornire una chiara documentazione sul significato di queste intestazioni. La maggior parte degli sviluppatori andrà direttamente alla documentazione quando vedranno queste intestazioni personalizzate, specialmente se vedono un limite. Puoi andare ancora oltre e mostrare il link nelle intestazioni. Oppure puoi mostrare un link alla pagina dei prezzi.

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

Ma ancora una volta, molti sviluppatori non sanno come funziona HTTP.

Quindi è la tua chiamata

Uno è più corretto, l'altro è più accessibile.

Varie

Alcune altre cose relative alla tua domanda:

• Non dimenticare 429 Troppe richieste .
• Non dimenticare l' intestazione della risposta WWW-Authenticate .

Come fa il cliente a sapere se può aggiornare il proprio ranking?

Dipende dal cliente. Normalmente è possibile inserire tali informazioni sotto forma di un messaggio ipertestuale (noto anche come HTML) nel corpo della risposta del metodo REST. Tuttavia, ciò ha senso solo se l'API REST viene utilizzata con un client HTML.

Simile per XML e JSON.

Modifica: potresti confondere usando un'API (espandi questo acronimo) con il marketing dei tuoi tipi di account / piani utente. Non lo mescolerei, poiché diventa sempre difficile (le decisioni aziendali potrebbero richiedere cambiamenti più rapidi rispetto ai cambiamenti nel software per comunicare risposte diverse a causa di questi cambiamenti in grado di arrivare sul piatto in tempo).

Invece, comunica ai tuoi utenti attraverso un canale diverso, ad esempio con la newsletter quali sono i loro vantaggi.

Funziona particolarmente bene quando la persona che si iscrive al servizio non è quella che sta programmando contro l'API. Per esempio:

George (che è un ragazzo orgogliosamente gay all'età di 36 gattini amorevoli) acquista l'accesso a cute-cats-4-me.com e dice al suo coniuge di 16 anni (che sta bene con i sistemi di scripting incluso Linux) di creare un applicazione di segnaletica digitale che mostra simpatici gattini sul muro dell'appartamento.

Quindi il ragazzo che si sta divertendo a programmare questo in realtà non è tanto il destinatario più diretto delle informazioni.

In alternativa, in risposta al login e un metodo di informazioni utente, fornire tutti i dettagli gory.

Ma quando un utente richiede gatti a livello di codice, dovrebbe già essere consapevole del motivo per cui recupera solo tre gatti o più. Ma non risolvi questo problema di comunicazione con il codice.

Altrimenti, consentire loro di interrogare di più e quindi restituire un avviso di errore se i loro diritti non sono sufficienti. Ma ancora una volta, questo non è un software facile da usare.