Tingkat izin pengguna dalam API ISTIRAHAT


23

Katakanlah saya memiliki perusahaan yang memberi peringkat kucing paling lucu di internet.

Saya menawarkan sumber daya di/cats/ mana memberikan kepada pengguna kucing terbaru yang lucu dan menggemaskan.

Pengguna bisa mendapatkan hanya 3 kucing teratas jika mereka belum membayar sama sekali atau terdaftar. 10 kucing teratas jika mereka membayar 337 dolar dan login, dan 100 kucing teratas jika mereka membayar 1337 dolar dan masuk. Saya memiliki 'pengidentifikasi pengguna' saat mengajukan permintaan.

Singkatnya, konsumen /cats/mendapatkan jumlah kucing yang berbeda berdasarkan 'peringkat pengguna' mereka . Saya memang memiliki pengidentifikasi pengguna di sisi pengguna, tetapi saya tidak memiliki representasi tingkat pengguna di sisi pengguna. Saya ingin memberi tahu pengguna bahwa mereka dapat meningkatkan langganan saat mengajukan permintaan. Artinya, saya harus membedakan antara 3 kucing karena saya hanya menawarkan 3 kucing dan 3 kucing karena itulah yang diizinkan tingkat pengguna .

Apa praktik terbaik untuk membedakan pembatasan sumber daya karena konsumen tidak memiliki hak istimewa yang memadai dan membatasi karena itulah yang dimiliki konsumen?

Bagaimana klien tahu jika mereka dapat meningkatkan peringkat mereka? Artinya, mereka hanya mendapat sumber daya terbatas karena mereka tidak memiliki izin. Apa praktik terbaik di sini?

Catatan, ini adalah penyederhanaan nyata dari kasus aktual. Juga, hanya untuk memperjelas - membaca dihargai.


Memperbarui:

Berikut ini beberapa opsi yang telah kami pertimbangkan:

  • Menyimpan objek izin pengguna sekali pada klien, meminta hanya ketika login atau upgrade akun dilakukan.
  • Melewati nullnilai dalam JSON yang menunjukkan ada, tetapi tidak ada yang sebenarnya ditransfer. Jadi 10 kucing untuk pengguna dengan 3 kucing bisa jadi["Garfield","Sylvester","Puss in Boots",null*7]
  • Melewati pasangan izin sumber daya {cats:["Whiskers","Fluffy","Socks"],authCount:3}

Saya ingin melakukan ini dengan benar pertama kali untuk memberikan kucing lucu dengan cara terbaik dan kami dan kami ingin


4
sekarang saya ingin melihat gambar-gambar kucing lucu
Carrie Kendall

Saya tidak mengerti. Jika Anda tidak menyimpan 'level pengguna' di mana pun, maka Anda tidak dapat membedakan. Sepertinya Anda tidak memiliki info pengguna yang tersimpan di server, jadi Anda tidak dapat menyimpan level pengguna mereka dengannya.
Jan Doggen

@ JanDoggen Saya memiliki level pengguna di server (klien menyampaikan pengenal ke server).
Benjamin Gruenbaum

Membantu? Saya tidak mendapatkan referensi 1337?
Marjan Venema

Jawaban:


18

Saya akan mengatakan itu tergantung pada audiens Anda.

No-dev

Jika audiens Anda bukan salah satu pengembang, aku akan pergi dengan cara sebagai berikut:

Katakanlah Anda kembali JSON demi contoh.

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

Atau yang serupa.

Sangat informatif bagi pengguna untuk mengetahui status akunnya, dan memungkinkan Anda untuk memasukkan informasi apa pun yang Anda inginkan, seperti pesan pemasaran. Hal yang paling penting dari cara ini adalah untuk memberikan beberapa visibilitas mudah untuk pengguna Anda dari akun mereka saat ini.

Dev

Namun, jika audiens Anda adalah murni pengembang, maka saya akan mengatakan: lanjutkan dengan cara HTTP compliant penuh. Untuk menyimpan metadata, Anda menggunakan HTTP header.

Berikut ini sebuah contoh:

GET /cats HTTP/1.1

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

Lalu, berikan dokumentasi yang jelas tentang arti header ini. Kebanyakan pengembang akan langsung ke dokumentasi ketika mereka akan melihat header kustom ini, terutama jika mereka melihat batas. Anda dapat melangkah lebih jauh dan menunjukkan tautan di header. Atau Anda dapat menunjukkan tautan ke halaman penetapan harga.

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

Tetapi sekali lagi, banyak pengembang tidak tahu cara kerja HTTP.

Jadi itu panggilanmu

Satu lebih benar, yang lain lebih mudah diakses.

Lain-lain

Beberapa hal lain yang terkait dengan pertanyaan Anda:


1
Ya, ini masuk akal, meskipun sebagai catatan saya menemukan beberapa informasi auth (ent / orize) yang masuk dalam header HTTP adalah pendekatan yang tepat karena metadata efektif.
Jimmy Hoffa

@JimmyHoffa Ini memang metadata, dan pikiran pertama saya adalah menggunakan header HTTP. Namun, dalam hal ini, tajuk HTTP tidak menawarkan visibilitas yang cukup bagi pelanggan, dan rincian yang dibutuhkan untuk pesan pemasaran. (Diedit jawaban untuk menambahkan detail ini.)
Florian Margaine

@JimmyHoffa bagaimana? 402 tidak dapat digunakan dalam kasus ini. Apa yang Anda sarankan?
Benjamin Gruenbaum

@BenjaminGruenbaum Saya tidak mengatakan kode respons, kataku tajuk; Anda dapat menambahkan semua tajuk ubahsuaian yang Anda inginkan untuk metadata, akan lebih bijaksana untuk memiliki semua tanggapan dari api yang tenang hanya memiliki peran pengguna di tajuk sebagai UserRole = level1atau apa pun yang Anda ingin panggil hanya untuk memastikan konsumen selalu sadar bagaimana cara menyajikan data apa pun yang mereka terima, dan konsisten di semua respons di mana model data yang kembali akan berbeda dari satu permintaan ke yang lain, konsumen selalu dapat memeriksa peran mereka dengan cara yang sama.
Jimmy Hoffa

1
@BenjaminGruenbaum Saya sudah benar-benar menulis ulang jawabannya.
Florian Margaine

4

Bagaimana klien tahu jika mereka dapat meningkatkan peringkat mereka?

Itu tergantung pada klien. Biasanya Anda dapat menempatkan informasi tersebut dalam bentuk pesan hyptertext (alias HTML) ke dalam tubuh respon dari metode REST. Namun itu hanya masuk akal jika REST API digunakan dengan klien HTML.

Mirip dengan XML dan JSON.


Sunting: Anda mungkin bingung menggunakan API (perluas akronim ini) dengan pemasaran tipe akun / paket pengguna Anda. Saya tidak akan mencampur ini, karena selalu mencurigakan (keputusan bisnis mungkin memerlukan perubahan yang lebih cepat daripada perubahan dalam perangkat lunak untuk mengkomunikasikan tanggapan yang berbeda karena perubahan ini dapat dilakukan pada waktu yang tepat).

Alih-alih memberi tahu pengguna Anda melalui saluran yang berbeda, misalnya dengan buletin apa manfaatnya.

Ini bekerja sangat baik ketika orang yang mendaftar ke layanan bukan orang yang memprogram melawan API. Sebagai contoh:

George (yang adalah lelaki gay yang bangga pada usia 36 anak kucing yang penuh kasih) membeli akses ke cute-cats-4-me.com dan memberi tahu pasangannya yang berusia 16 tahun (yang baik dengan sistem komputer scripting termasuk linux) untuk membuat aplikasi signage digital menampilkan kucing imut kecil yang bagus di dinding di apartemen.

Jadi pria yang bersenang-senang memprogram ini sebenarnya bukan penerima informasi yang paling mudah.

Atau sebagai respons terhadap login dan metode info-pengguna, berikan semua detail berdarah.

Tetapi ketika seorang pengguna meminta kucing secara terprogram, ia seharusnya sudah mengetahui mengapa ia hanya mendapatkan tiga kucing kembali atau lebih. Tetapi Anda tidak menyelesaikan masalah komunikasi ini dengan kode.

Jika tidak, izinkan mereka untuk meminta lebih dan kemudian memberikan pemberitahuan kegagalan jika hak mereka tidak memadai. Tetapi sekali lagi, itu bukan perangkat lunak yang ramah pengguna.


1
@Racheet: Apakah Anda memiliki masalah ketika anak perempuan memiliki uang di rumah dan memberi tahu anak laki-laki apa yang harus dilakukan?
hakre

1
Saya memiliki masalah dengan contoh yang menyatakan bahwa perempuan membutuhkan pacar untuk melakukan pemrograman untuk mereka.
Racheet
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.