Livelli di permessi utente in un'API RESTful

Naviga le tue risposte
23

Diciamo che ho una società che classifica i gatti più carini su Internet.

Offro una risorsa a /cats/ che fornisce agli utenti i più adorabili e adorabili gatti.

Gli utenti possono ottenere solo i primi 3 gatti se non hanno pagato affatto o registrati. I 10 migliori gatti se hanno pagato 337 dollari e hanno effettuato l'accesso, e i primi 100 gatti se hanno pagato 1337 dollari e hanno effettuato l'accesso. Ho un 'identificativo utente' quando faccio la richiesta.

In breve, i consumatori di /cats/ ottengono un numero diverso di gatti in base al loro 'utente classifica '. Ho un identificativo utente sulla parte consumante, ma non ho alcuna rappresentazione esplicita del livello utente sulla parte consumante. Vorrei informare gli utenti che possono aggiornare l'abbonamento quando si effettua la richiesta. Cioè, ho bisogno di 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 privilegi sufficienti e la limita perché è ciò che il consumatore ha?

Come fa il cliente a sapere se è possibile aggiornare il proprio ranking? Cioè, hanno solo una risorsa limitata perché loro non hanno permessi. Qual è la migliore pratica qui?

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

Aggiornamento:

Ecco le opzioni che abbiamo considerato:

  • Archivia gli oggetti delle autorizzazioni utente una sola volta sul client, interrogandoli solo quando viene eseguito l'accesso o l'aggiornamento dell'account.
  • Passaggio di valori di null in JSON che indica che esiste, ma un niente reale è stato trasferito. Quindi 10 gatti per un utente con 3 gatti potrebbero essere ["Garfield","Sylvester","Puss in Boots",null*7]
  • Passaggio di una coppia di autorizzazioni di risorsa {cats:["Whiskers","Fluffy","Socks"],authCount:3}

Mi piacerebbe farlo giusto la prima volta per offrire i gatti più carini nel miglior modo possibile e vorremmo e vorremmo

    
posta Benjamin Gruenbaum 08.07.2013 - 15:47
fonte

2 risposte

17

Direi che dipende dal tuo pubblico.

No-dev

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

Supponiamo che tu restituisca JSON per l'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.

È utile che l'utente sappia quale sia lo stato del suo account e ti consente di inserire qualsiasi informazione tu voglia, ad esempio un messaggio di marketing. Il punto più importante di questo modo è dare una certa visibilità agli utenti del loro account corrente.

Dev

Tuttavia, se il tuo pubblico è puramente sviluppatore, allora direi: segui il metodo completo conforme a HTTP. Per memorizzare i metadati, usi 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 di cosa significano 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 poi di nuovo, 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:

risposta data 08.07.2013 - 15:57
fonte
4

How does the client know if they can upgrade their ranking?

Dipende dal cliente. Normalmente è possibile inserire tali informazioni sotto forma di un messaggio di ipertesto (detto anche 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 vorrei mescolare questo, 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 che sono in grado di arrivare sul piatto in tempo).

Dì invece ai tuoi utenti attraverso un canale diverso, ad es. con la newsletter quali sono i loro benefici.

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

George (who is a proudly gay guy at the age of 36 loving kittens) buys access to cute-cats-4-me.com and tells his 16 year old spouse (who is well with scripting computer systems incl. linux) to create a digital signage application displaying nice little cutie kitties on the wall in the apartment.

Quindi il ragazzo che si diverte a programmarlo in realtà non è il destinatario più diretto dell'informazione.

In alternativa, in risposta al login e a un metodo di informazioni utente, fornisci tutti i dettagli cruenti.

Ma quando un utente richiede i gatti a livello di programmazione, dovrebbe già sapere perché ha solo tre gatti indietro o più. Ma non risolvi questo problema di comunicazione con il codice.

Altrimenti, consenti loro di interrogare di più e poi restituire un avviso di fallimento se i loro diritti non sono sufficienti. Ma ancora, questo non è un software facile da usare.

    
risposta data 08.07.2013 - 15:53
fonte

Leggi altre domande sui tag

Quando (e quando no) usare Wordpress? [chiuso] Quanto spesso viene usato il seq nel codice di produzione Haskell?