RESTful API'deki kullanıcı izinleri düzeyleri

Diyelim ki internetteki en sevimli kedileri sıralayan bir şirketim var.

/cats/Kullanıcılara en sevimli ve sevimli kedileri sağlayan bir kaynak öneriyorum .

Kullanıcılar, hiç ödeme yapmadıysa veya kaydolduysa ilk 3 kediyi alabilir. 337 dolar ödemiş ve giriş yapmışlarsa ilk 10 kedi, 1337 dolar ödemiş ve giriş yapmışlarsa ilk 100 kedi. Talepte bulunurken bir 'kullanıcı tanımlayıcı' var.

Kısacası, tüketiciler /cats/'kullanıcı sıralamasına' göre farklı sayıda kedi almaktadır . Tüketici ucunda bir kullanıcı tanımlayıcım var, ancak tüketici ucunda kullanıcı düzeyini açıkça temsil etmiyorum. Kullanıcılara , isteklerini yaparken aboneliklerini yükseltebileceklerini bildirmek istiyorum . Yani, sadece 3 kedi ve 3 kedi sunduğum için 3 kediyi ayırt etmem gerekiyor çünkü kullanıcı seviyesinin izin verdiği şey bu .

Tüketici yeterli ayrıcalıklara sahip olmadığından ve onu sınırlandırdığından, tüketicinin sahip olduğu şey bu olduğundan, kaynağı sınırlandırmak için en iyi uygulama nedir?

Müşteri sıralamasını yükseltip yükseltemeyeceğini nasıl bilebilir? Çünkü Yani, bunlar sadece sınırlı kaynak vardır onlar izniniz yok. Buradaki en iyi uygulama nedir?

Not, bu gerçek durumun brüt bir sadeleştirme olduğunu. Ayrıca, sadece netleştirmek için - okuma takdir edilir.

Güncelleştirme:

İşte düşündüğümüz seçenekler:

• Kullanıcı izin nesnelerini istemcide bir kez depolamak, yalnızca hesap oturumu açma veya yükseltme gerçekleştirildiğinde sorgulama yapmak.
• JSON'da nulldeğerlerin geçtiğini gösteren, ancak gerçek hiçbir şey transfer edilmedi. Yani 3 kedi ile bir kullanıcı için 10 kedi olabilir["Garfield","Sylvester","Puss in Boots",null*7]
• Kaynak izin çiftini geçmek {cats:["Whiskers","Fluffy","Socks"],authCount:3}

En tatlı kedileri mümkün olan en iyi şekilde sunmak için ilk kez bunu doğru yapmak isterdim ve isteriz ve isteriz

İzleyicilerinize bağlı olduğunu söyleyebilirim.

Hayır-dev

Kitleniz bir geliştiricinin değilse, aşağıdaki şekilde giderim:

Diyelim ki, örnek uğruna JSON'u iade ettiniz.

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

Veya benzeri.

Kullanıcının hesabının durumunun ne olduğunu bilmesi bilgilendiricidir ve bir pazarlama mesajı gibi istediğiniz bilgileri girmenize olanak tanır. Bu yolla en önemli nokta, kullanıcılarınıza cari hesaplarında kolaylık sağlamak.

dev

Bununla birlikte, hedef kitleniz tamamen geliştiriciler ise, derim ki: tam HTTP uyumlu yoldan devam edin. Meta verileri depolamak için HTTP üstbilgileri kullanırsınız.

İşte bir örnek:

GET /cats HTTP/1.1

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

Ardından, bu başlıkların ne anlama geldiğinin açık bir belgelendirmesini sağlayın. Çoğu geliştirici, bu özel başlıkları, özellikle de bir sınır görüyorlarsa, görecekleri zaman belgelendirmeye gider. Daha da ileri giderek bağlantıyı başlıklarda gösterebilirsiniz. Veya fiyatlandırma sayfasına bir link gösterebilirsiniz.

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

Fakat yine, birçok geliştirici HTTP'nin nasıl çalıştığını bilmiyor.

Demek telefonun

Biri daha doğru, diğeri daha erişilebilir.

Çeşitli

Sorunuzla ilgili diğer bazı diğer şeyler:

• Unutma 429 Çok fazla istek var .
• WWW-Kimlik doğrulaması yanıt başlığını unutma .

Müşteri sıralamasını yükseltip yükseltemeyeceğini nasıl bilebilir?

Bu müşteriye bağlı. Normalde bu tür bilgileri REST yönteminin cevap gövdesine bir hipermetin mesajı (aka HTML) şeklinde koyabilirsiniz. Ancak bu yalnızca REST API bir HTML istemcisi ile kullanıldığında anlamlıdır.

XML ve JSON için benzer.

Düzenleme: Bir API kullanarak (bu kısaltmayı genişleterek) hesap türlerinizin / kullanıcı planlarınızın pazarlanmasıyla karıştırabilirsiniz. Her zaman balığa girdiği için bunu karıştırmam (iş kararları, zaman zaman tablaya girebilmeleri nedeniyle farklı yanıtları iletmek için yazılımdaki değişikliklerden daha hızlı değişiklikler gerektirebilir).

Bunun yerine kullanıcılarınıza farklı bir kanal üzerinden, örneğin haber bülteninde faydalarının ne olduğunu söyleyin.

Bu, özellikle hizmete kaydolan kişi API'ye karşı programlama yapan kişi olmadığında işe yarar. Örneğin:

George (36 yaşında sevgili kedi yavrularıyla gururla eşcinsel bir erkek olan) cute-cats-4-me.com sitesine erişim satın alır ve 16 yaşındaki eşine (linux dahil komut dosyası kullanan bilgisayar sistemlerini iyi kullanan) apartmanda duvarda güzel küçük tatlı kedi yavruları gösteren dijital tabela uygulaması.

Bu yüzden, bunu programlamaktan hoşlanan adam aslında bilginin en yalın adresi değildi.

Alternatif olarak, oturum açma ve bir kullanıcı bilgisi yöntemine cevap olarak, tüm kanlı ayrıntıları sağlayın.

Ancak bir kullanıcı kedileri programlı olarak talep ettiğinde, neden sadece üç kedi geri veya daha fazla aldığının farkında olmalıdır. Ancak bu iletişim sorununu kod ile çözemezsiniz.

Aksi takdirde, daha fazla sorgulamalarına izin verin ve sonra hakları yeterli değilse bir başarısızlık bildirimi verin. Fakat yine de bu kullanıcı dostu bir yazılım değil.