Biraz açıklığa ihtiyacım var. REST hakkında okudum ve RESTful uygulamaları geliştirdim. Vikipedi'ye göre, REST'in kendisi Temsili Devlet Transferi olarak tanımlanmaktadır . Bu nedenle herkesin püskürttüğü bu vatansız gobbledeygook'u anlamıyorum .

Vikipedi'den:

Herhangi bir zamanda, bir istemci ya uygulama durumları arasında geçiş yapabilir ya da "hareketsiz" olabilir. Bekleme durumundaki bir istemci, kullanıcısıyla etkileşim kurabilir, ancak yük oluşturmaz ve sunucu kümesinde veya ağda istemci başına depolama alanı kullanmaz.

Sadece oturum / uygulama düzeyinde veri deposu kullanma mı diyorlar ???

REST'in bir amacının URI erişimini tutarlı ve kullanılabilir hale getirmektir, örneğin mesajların içindeki sayfalama isteklerini gizlemek, bir isteğin sayfa numarasını GET URI'sının bir parçası haline getirmek. Bana mantıklı geldi. Ancak, istemci başına hiçbir veri (oturum verisi) sunucu tarafında saklanmaması gerektiğini söyleyerek aşırıya kaçıyor gibi görünüyor .

Bir mesaj kuyruğum olsaydı ve kullanıcım mesajları okumak istiyordu, ancak okudukça, belirli gönderenlerin oturumu boyunca gelen mesajları engellemek istiyordu? Bunu sunucu tarafında bir yerde saklamak ve sunucunun yalnızca kullanıcı tarafından engellenmeyen mesajlar (veya mesaj kimlikleri) göndermesini sağlamak anlamlı olmaz mı?

Yeni ileti listesini her istediğimde engellemek için ileti gönderenlerin tam listesini göndermem gerekiyor mu? Benim için uygun olan mesaj listesi, ilk etapta halka açık bir kaynak bile olmaz / olmamalıdır.

Yine, sadece bunu anlamaya çalışıyorum. Birisi lütfen açıkla.

Güncelleme:

Beni tam olarak oraya götürmeyen bir cevabı olan bir yığın taşma sorusu buldum: REST'te durumun nasıl yönetileceği , önemli olan istemci durumun her istek üzerine aktarılması gerektiğini söyleyen .... Ugg .. çok fazla yük gibi görünüyor ... Bu doğru mu ??

Vatansızlık, her HTTP isteğinin tamamen yalıtıldığı anlamına gelir. İstemci bir HTTP isteği yaptığında, sunucunun bu isteği yerine getirmesi için gereken tüm bilgileri içerir. Sunucu asla önceki isteklerden gelen bilgilere dayanmaz. Bu bilgi önemliyse, müşterinin sonraki talepte bu bilgileri tekrar göndermesi gerekir. Vatansızlık da yeni özellikler getiriyor. Durum bilgisi olmayan bir uygulamayı yük dengeli sunucular arasında dağıtmak daha kolaydır. Vatansız bir uygulamanın önbelleğe alınması da kolaydır.

Aslında iki tür devlet vardır. İstemcide yaşayan Uygulama Durumu ve sunucuda yaşayan Kaynak Durumu.

Bir web hizmetinin yalnızca gerçekten bir istekte bulunduğunuzda uygulama durumunuza dikkat etmesi gerekir. Geri kalan zamanda, varlığınızı bile bilmiyor. Bu, bir istemci her istek yaptığında, sunucunun isteği işlemesi gereken tüm uygulama durumlarını içermesi gerektiği anlamına gelir.

Kaynak durumu her istemci için aynıdır ve uygun yeri sunucudadır. Bir sunucuya resim yüklediğinizde, yeni bir kaynak oluşturursunuz: yeni resmin kendi URI'si vardır ve gelecekteki isteklerin hedefi olabilir. HTTP aracılığıyla bu kaynağı getirebilir, değiştirebilir ve silebilirsiniz.

Umarım bu durum vatansızlığın ve çeşitli devletlerin ne anlama geldiğini ayırt etmeye yardımcı olur.

Temel açıklama:

Sunucuda istemci oturumu durumu yok.

Vatansız olarak bunun anlamı , sunucu hakkında herhangi bir durumu saklamaz istemci oturumu sunucu tarafında.

İstemci oturumu istemci üzerinde saklanır. Sunucu durumsuzdur, her sunucunun herhangi bir istemciye herhangi bir zamanda hizmet verebileceği, oturum benzeşimi veya yapışkan oturumlar olmadığı anlamına gelir . İlgili oturum bilgileri istemcide depolanır ve gerektiğinde sunucuya iletilir.

Bu, web sunucusunun konuştuğu diğer hizmetleri, yalnızca müşterinin geçerli uygulama / oturum durumu hakkında değil, alışveriş sepetleri gibi iş nesneleriyle ilgili durumu korumaktan alıkoymaz.

Müşterinin uygulama durumu sunucuda depolanan, ancak yaklaşık geçirilen asla istemci ihtiyacı her yere.

İşte bu noktada ST içinde DİNLENME gelmektedir Devlet Transferi . Sunucunun depolamasını sağlamak yerine durumu aktarırsınız. Milyonlarca eşzamanlı kullanıcıyı ölçeklendirmenin tek yolu budur. Milyonlarca seans milyonlarca seanstan başka bir nedenden ötürü değilse.

Oturum yönetiminin yükü tüm istemciler arasında amortismana tabi tutulur, istemciler oturum durumlarını depolar ve sunucular çok sayıda veya daha fazla istemciye vatansız bir şekilde hizmet verebilir.

Sadece binlerce eşzamanlı binlerce kullanıcının ihtiyacı olacağını düşündüğünüz bir hizmet için bile , hizmetinizi vatansız yapmalısınız. On binlerce hala on binlerce ve bununla ilişkili zaman ve alan maliyeti olacak.

Vatansız, HTTP protokolünün ve web'in genel olarak nasıl çalışacağı ve genel olarak daha basit bir uygulamadır ve bir grup oturum durumunu korumak için bir grup sunucu tarafı mantığı yerine tek bir kod yolunuz vardır.

Bazı çok temel uygulama ilkeleri vardır:

Bunlar uygulama değil ilkelerdir, bu ilkeleri nasıl karşıladığınız değişebilir.

Özet olarak, beş temel ilke şunlardır:

1. Her "şeye" bir kimlik verin
2. Bir şeyleri birbirine bağlayın
3. Standart yöntemler kullanın
4. Birden fazla temsili olan kaynaklar
5. Vatansız iletişim kurun

REST tezinde kimlik doğrulama veya yetkilendirme hakkında hiçbir şey yoktur .

Çünkü RESTful olmayan bir isteği doğrulamaktan farklı bir şey yoktur. Kimlik doğrulama, RESTful tartışması ile ilgisizdir.

Özel gereksinimleriniz için durum bilgisi olmayan bir uygulamanın nasıl oluşturulacağını açıklamak StackOverflow için çok geniştir .

REST ile ilgili olduğu için Kimlik Doğrulama ve Yetkilendirmenin uygulanması çok daha geniştir ve uygulamalara yönelik çeşitli yaklaşımlar genel olarak internette ayrıntılı olarak açıklanmaktadır.

Bu konuda yardım / bilgi isteyen yorumlar sadece Artık Gerek Yok olarak işaretlenecek / işaretlenecektir .

Sadece oturum / uygulama düzeyinde veri deposu kullanma mı diyorlar ???

Hayır. Bunu önemsiz bir şekilde söylemiyorlar.

Bir "oturum" tanımlamıyor diyorlar. Giriş yapma. Çıkış yapma. İstekte kimlik bilgileri sağlayın. Her istek yalnız kalır.

Hala veri depolarınız var. Hala kimlik doğrulamanız ve yetkiniz var. Oturum oluşturmak ve oturum durumunu korumak için zaman kaybetmeyin.

Mesele şu ki, her istek (a) tamamen tek başına durmaktadır ve (b) önemsiz bir şekilde gerçek bir iş yapmadan dev bir paralel sunucu çiftliğine dağıtılabilir. Apache veya Squid RESTful isteklerini körü körüne ve başarılı bir şekilde iletebilir.

Bir mesaj kuyruğum olsaydı ve kullanıcım mesajları okumak istiyordu, ancak okudukça, belirli gönderenlerin oturumu boyunca gelen mesajları engellemek istiyordu?

Kullanıcı bir filtre istiyorsa, her istekte filtreyi sağlamanız yeterlidir.

Sunucunun yalnızca kullanıcı tarafından engellenmeyen mesajlar (veya mesaj kimlikleri) göndermesi anlamlı olmaz mıydı?

Evet. Filtreyi RESTful URI isteğinde sağlayın.

Yeni ileti listesini her istediğimde engellemek için ileti gönderenlerin tam listesini göndermem gerekiyor mu?

Evet. Bu "engellenecek mesaj gönderenlerin listesi" ne kadar büyük olabilir? PK'ların kısa bir listesi?

Bir GET isteği çok büyük olabilir. Gerekirse, bir tür sorgu gibi görünse bile bir POST isteği deneyebilirsiniz.

Kesinlikle haklısınız, sunucu ile tamamen vatansız etkileşimleri desteklemek istemciye ek bir yük getiriyor. Ancak, bir uygulamayı ölçeklendirmeyi düşünüyorsanız, istemcilerin hesaplama gücü, istemci sayısıyla doğru orantılıdır. Bu nedenle çok sayıda müşteriye ölçeklendirme yapmak çok daha uygundur.

Belirli bir müşterinin etkileşimleriyle ilgili bazı bilgileri yönetmek için sunucuya küçük bir sorumluluk koyar koymaz, bu yük sunucuyu tüketmek için hızla büyüyebilir.

Bu bir takas.

Kullanıcı uygulama durumu yönetiminin tarihsel görünümü

Geleneksel anlamda oturumlar, kullanıcının durumunu sunucu içindeki uygulamada tutar. Bu, bir akıştaki geçerli sayfa veya daha önce girilmiş ancak ana veritabanında henüz bulunmayan sayfa olabilir.

Bu ihtiyacın nedeni, istemciye özgü (yani tarayıcıya özgü) uygulamalar veya eklentiler yapmadan durumu etkin bir şekilde korumak için istemci tarafında standartların olmamasıydı.

HTML5 ve XML Üstbilgi İsteği, zaman içinde sunucu arasında ileri ve geri gitmeye gerek kalmadan uygulama durumu dahil karmaşık verilerin standart şekilde istemci (yani tarayıcı) tarafında depolanması kavramını standartlaştırmıştır.

REST hizmetlerinin genel kullanımı

REST hizmetleri genellikle gerçekleştirilmesi gereken bir işlem olduğunda veya veri alması gerektiğinde çağrılır.

REST hizmetleri, doğrudan son kullanıcı tarafından değil, istemci tarafı uygulaması tarafından çağrılmalıdır.

Kimlik doğrulanıyor

Sunucuya yapılan herhangi bir istek için, isteğin bir kısmı yetkilendirme belirtecini içermelidir. Nasıl uygulanır uygulamaya özel olmakla birlikte, genel olarak bir ya olduğu BASICveya CERTIFICATEkimlik doğrulama formu.

Form tabanlı kimlik doğrulaması REST hizmetleri tarafından kullanılmaz. Ancak, yukarıda belirtildiği gibi REST hizmetleri kullanıcı tarafından değil uygulama tarafından çağrılmalıdır. Uygulamanın kimlik doğrulama jetonunu almayı yönetmesi gerekir. Benim durumumda , kimlik doğrulama için Google'a bağlanmak için OAuth 2.0 ile JASPIC ile çerezler ve otomatik test için basit HTTP Kimlik Doğrulaması kullandım. Ayrıca yerel testler için JASPIC üzerinden HTTP Üstbilgisi kimlik doğrulamasını da kullandım (ancak aynı yaklaşım SiteMinder'da da yapılabilir)

Bu örneklere göre, kimlik doğrulama istemci tarafında yönetilir (SiteMinder veya Google kimlik doğrulama oturumunu sonunda saklasa da), bu durumla ilgili yapılabilecek hiçbir şey yoktur, ancak REST hizmeti uygulamasının bir parçası değildir.

Alma istekleri

REST'teki alma istekleri, GETbelirli bir kaynağın istendiği ve önbelleğe alınabildiği işlemlerdir. Sunucu oturumlarına gerek yoktur, çünkü istek verileri almak için gereken her şeye sahiptir: kimlik doğrulama ve URI.

İşlem komut dosyaları

Yukarıda belirtildiği gibi, istemci tarafı uygulaması, istemci tarafında da yönettiği kimlik doğrulamasının yanı sıra REST hizmetlerini de çağırır.

[Doğru yapılırsa] tek bir işlemde gerekli olan her şeyi yapar, tek bir kullanıcı işlemi için gerekli olan her şeyi içerecek DİNLENME sunucuya tek isteği almaktır DİNLENME hizmetler için ne anlama geliyor, bir İşlem Senaryo neyi kalıptır denir.

Bu POSTgenellikle bir istek yoluyla yapılır , ancak diğerleri gibi PUTde kullanılabilir.

REST'in bir çok örneği (bunu kendim yaptım), HTTP protokolünde tanımlananları takip etmeye çalıştım, daha sonra pragmatik olmaya karar verdim ve sadece GET ve POST'a bıraktım . POSTYöntem bile SONRASI YENİDEN YÖNLENDİRME-GET deseni uygulamak zorunda değildir.

Yine de, yukarıda belirttiğim gibi, istemci tarafı uygulama hizmeti çağıran olacak ve sadece POSTihtiyaç duyulduğunda (her zaman değil) tüm veri ile isteği çağıracaktır . Bu sunucuya sürekli istekleri önler.

oy verme

REST sorgulama için de kullanılabilse de, tarayıcı uyumluluğu nedeniyle kullanmanız gerekmedikçe bunu tavsiye etmeyeceğim. Bunun için de bir API sözleşmesi tasarlamış olduğum WebSockets'i kullanırım . Eski tarayıcılar için başka bir alternatif CometD'dir.

REST çok soyut. Bazı iyi, basit, gerçek dünya örnekleri elde etmeye yardımcı olur.

Örneğin tüm büyük sosyal medya uygulamalarını ele alalım - Tumblr, Instagram, Facebook ve Twitter. Hepsinde aşağıya doğru ilerlediğinizde, daha fazla içerik gördüğünüz, daha fazla ve daha geriye döndüğünüzde sonsuza kadar kaydırılan bir görünüm vardır. Bununla birlikte, hepiniz, kaydırdığınız yeri kaybettiğiniz anı yaşadık ve uygulama sizi en üste sıfırlıyor. Uygulamadan çıktığınızda, tekrar açtığınızda tekrar en üstte olursunuz.

Bunun nedeni, sunucunun oturum durumunuzu saklamadığıdır. Ne yazık ki, kaydırma konumunuz istemcideki RAM'de saklandı.

Neyse ki yeniden bağlandığınızda tekrar giriş yapmak zorunda değilsiniz, ancak bunun nedeni yalnızca istemci tarafında depolanan oturum açma sertifikanızın süresinin dolmamış olmasıdır. Uygulamayı silin ve yeniden yükleyin; sunucu IP adresinizi oturumunuzla ilişkilendirmediği için tekrar giriş yapmanız gerekir.

Sunucuda bir oturumunuz yok, çünkü REST'e uyuyorlar.

Şimdi yukarıdaki örnekler hiç bir web tarayıcısı içermiyor, ancak arka tarafta uygulamalar HTTPS üzerinden ana sunucularıyla iletişim kuruyor. Demek istediğim, REST'in çerezleri ve tarayıcıları vb. İçermesi gerekmediğidir. İstemci tarafı oturum durumunu depolamanın çeşitli yolları vardır.

Ancak bir saniye boyunca web tarayıcıları hakkında konuşalım, çünkü bu, burada kimsenin bahsetmediği REST'in başka bir büyük avantajını getiriyor.

Sunucu oturum durumunu saklamaya çalıştıysa, her bir istemciyi nasıl tanımlaması gerekir?

IP adresleri kullanılamadı çünkü birçok kişi aynı adresi paylaşılan bir yönlendiricide kullanıyor olabilir. Öyleyse nasıl?

MAC adresini birçok nedenden dolayı kullanamazsınız, en azından değil, farklı tarayıcılarda artı uygulamada aynı anda birden fazla farklı Facebook hesabına giriş yapabilirsiniz. Bir tarayıcı kolayca başka bir tarayıcı gibi davranabilir ve MAC adreslerini taklit etmek de kolaydır.

Sunucunun sizi tanımlamak için bir istemci tarafı durumu depolaması gerekiyorsa, isteklerinizi işlemek için gereken süreden daha uzun süre RAM'de saklaması gerekir, aksi takdirde bu verileri önbelleğe almalıdır. Sunucular, işlemci hızından bahsetmeden, sınırlı miktarda RAM ve önbelleğe sahiptir. Sunucu tarafı durumu, üçüne de katlanarak ekler. Ayrıca, sunucu oturumlarınızla ilgili herhangi bir durumu depolayacaksa, oturum açmış olduğunuz her tarayıcı ve uygulama ve ayrıca kullandığınız her farklı cihaz için ayrı olarak depolaması gerekir.

Öyleyse ... Umarım şimdi REST'in ölçeklenebilirlik için neden bu kadar önemli olduğunu görüyorsunuz. Umarım sunucu tarafındaki oturum durumunun neden kaynak örslerin araç hızlandırması için sunucu ölçeklenebilirliği olduğunu görmeye başlayabilirsiniz.

İnsanların kafasının karıştığı yer, "devlet" in bir veritabanında depolanan bilgilere atıfta bulunduğunu düşünmektir. Hayır, kullanırken sunucunun RAM'inde olması gereken tüm bilgileri ifade eder.

Buradaki temel sorunun Oturumu Devlet ile karıştırdığını görüyorum . REST, Durumu sunucuda saklamamanız gerektiğini belirtirken , hiçbir şey bir kullanıcı oturumunu depolamanızı engellemez .

Sunucudaki Durumu yönetmek, sunucunuzun istemcinin ne yaptığını tam olarak bildiği anlamına gelir (uygulamanın hangi bölümünde görüntülüyorlar). Ve bunu yapmanıza gerek yok.

Oturum depolamasını minimum boyutta tutmanız gerektiğini söyleyen diğer insanlarla aynı fikirdeyim; ve bu sağduyu olsa da, aslında uygulamaya da bağlıdır. Kısacası, sunucuda daha az yüklenen istekleri işlemek için önbelleğe alınmış verilerle bir oturum devam ettirebilir ve istemcinin kullanması için geçici bir kimlik doğrulama / erişim belirteci sağlayarak kimlik doğrulamasını yönetebilirsiniz. Oturum / jetonun süresi dolduğunda yeni bir tane oluşturun ve istemciden bunu kullanmasını isteyin.

Birisi müşterinin jetonu daha iyi oluşturması gerektiğini iddia edebilir. Her iki şekilde de çalıştığını ve uygulamaya ve API ile kimin çalışacağına bağlı olacağını söylüyorum.

Ayrıca bazı hassas oturum verilerini sunucuda tutmanın doğru yolu olmalıdır. (Örneğin) "isFreeGift" adlı bir alan içeren alışveriş sepetlerini saklaması için müşteriye güvenemezsiniz. Bu tür bilgiler sunucuda tutulmalıdır.

Cevabında Santanu Dey tarafından sağlanan video bağlantısı yardımcı olur. Eğer izlemediysen izle.

Sadece bir yan not: Verilen tüm cevapların bazı işlemlerin sunucuda ağır bir yüke neden olabileceği gerçeğini göz ardı ettiği görülüyor. Bu güç tüketimi, donanım tüketimi ve maliyet açısından önemlidir (CPU çevrimi ile kiralanan sunucular için). İyi bir geliştirici, elektrik ve bakım faturasını ödemedikleri bazı kiralık bir sunucuda modern bir CPU'da çok hızlı bir şekilde yapılabilse bile, uygulamalarını optimize etmede tembel olmamalıdır.

Soru birkaç yaşında, umarım cevabım yine de yardımcı olacaktır.

Vatansız, hizmetin durumunun sonraki istekler ve yanıt arasında kalmayacağı anlamına gelir. Her istek kendi kullanıcı kimlik bilgilerini taşır ve tek tek kimlik doğrulaması yapılır. Ancak durum bilgisi dahilinde, her talep önceki herhangi bir talepten bilinmektedir. Tüm durum bilgisi olan istekler oturum yönelimlidir, yani her isteğin önceki isteklerde yapılan değişiklikleri bilmesi ve saklaması gerekir.

Bankacılık uygulaması, durum bilgisi olan uygulamalara bir örnektir. Kullanıcı ilk oturum açtıktan sonra işlem yapar ve oturumu kapatır. Oturumu kapattıktan sonra kullanıcı işlemi yapmaya çalışırsa, bunu yapamaz.

Evet, http protokolü temel olarak durum bilgisi olmayan bir protokoldür, ancak bunu bildirmek için bizi HTTP çerezleri yapıyoruz. Yani, varsayılan olarak SOAP. Ancak kullandığınız çerçeveye bağlı olarak aynı şekilde durum bilgisi olabilir.

HTTP vatansızdır, ancak java uygulamamızda farklı oturum izleme mekanizması kullanarak oturumu sürdürebiliriz.

Evet, REST veya SOAP olsun, web hizmetinde oturum da devam ettirebiliriz. Herhangi bir üçüncü taraf kütüphanesi kullanılarak uygulanabilir veya kendi kütüphanemiz tarafından uygulanabilir.

Http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap adresinden alınmıştır.

Hiç kaşık yok.

Vatansızlığı " tüm dosyalarınızı tekrar tekrar sunucuya gönderme" gibi düşünmeyin . Olmaz. Her zaman, devlet olacak - veritabanı kendisi olduğunu sonuçta devletin bir tür, kayıtlı bir kullanıcıysanız, istemci tarafında bilgi herhangi kümesi sunucu tarafında olmadan geçerli olmayacaktır böylece. Teknik olarak, asla gerçekten vatansız değilsiniz .

Her Tartışmada Oturum Açma ile ilgili bir kelime

Her seferinde oturum açmamak ve oturum açmamak ne anlama geliyor? Bazıları "her seferinde şifreyi gönder" anlamına gelir, bu sadece aptalca. Bazıları "nah elbette değil, bunun yerine bir jeton gönder " diyor - lo ve bak, PHP oturumu neredeyse tam olarak bunu yapıyor. Bir tür belirteç olan bir oturum kimliği gönderir ve her seferinde u / pw göndermeden kişisel öğelerinize ulaşmanıza yardımcı olur. Ayrıca oldukça güvenilir ve iyi test edilmiş. Ve evet, uygun, bir dezavantaja dönüşebilir, bir sonraki paragrafa bakın.

Ayak izini azaltın

Bunun yerine yapmanız gereken ve gerçek anlamda mantıklı olan, web sunucusu ayak izinizi en aza indirmektir. PHP gibi diller, oturum depolama alanındaki her şeyi doldurmayı çok kolaylaştırır - ancak oturumların bir fiyat etiketi vardır. Birden fazla web sunucunuz varsa, yükü de paylaştıkları için oturum bilgilerini paylaşmaları gerekir - herhangi birinin bir sonraki isteği sunması gerekebilir.

Paylaşılan bir depolama alanı şarttır. Sunucunun en azından birinin oturum açıp açmadığını bilmesi gerekir. (Ve buna her karar vermeniz gerektiğinde veritabanını rahatsız ederseniz, neredeyse mahkum olursunuz.) Paylaşılan depoların veritabanından çok daha hızlı olması gerekir. Bu cazibeyi getirir: tamam, çok hızlı bir depolama alanım var, neden her şeyi orada yapmıyorsun? - ve işte tam tersi işler böyle olur.

Yani, oturum depolama alanını minimumda tutmak mı diyorsunuz?

Yine, bu senin kararın. Performans nedenlerinden ötürü orada şeyler saklayabilirsiniz (veritabanı neredeyse her zaman Redis'ten daha yavaştır), bilgileri gereksiz bir şekilde depolayabilir, kendi önbelleğinizi uygulayabilirsiniz, ne olursa olsun - çok fazla çöp depolarsanız web sunucularının daha büyük bir yüke sahip olacağını unutmayın. onlar üzerinde. Ayrıca, ağır yükler altında kırılırlarsa (ve olacaklar), değerli bilgileri kaybedersiniz; REST düşünce tarzı ile, bu durumda olan her şey, müşteri aynı (!) isteği tekrar gönderir ve bu sefer servis edilir.

O zaman nasıl yapılır?

Burada herkese uyan hiçbir çözüm yok. Bir vatansızlık seviyesi seçin ve bununla devam edin. Oturumlar bazıları tarafından sevilebilir ve diğerleri tarafından nefret edilebilir, ancak hiçbir yere gitmezler. Her istekte, mantıklı olduğu kadar çok bilgi gönderin, belki biraz daha; ancak vatansızlığı bir oturum yapmamak veya her seferinde giriş yapmak olarak yorumlamayın. Her nasılsa sunucu onun sen olduğunu bilmeli ; PHP oturum kimlikleri iyi bir yoldur, manuel olarak oluşturulan jetonlar başka bir şeydir.

Düşün ve karar ver, tasarım trendlerinin senin için düşünmesine izin verme.

Bu sunuma bir göz atın.

http://youtu.be/MRxTP-rQ-S8

Bu desene göre - gerçekten ihtiyaç duyulduğunda ve gerektiğinde durumu yönetmek için geçici ve huzurlu kaynaklar oluşturun. Açık oturumlardan kaçının.

Durum bilgisi olmayan ve durum bilgisi olan arasındaki en büyük fark, verilerin her seferinde sunucuya aktarılmasıdır. Vatansız olması durumunda, müşteri tüm bilgileri sağlamalıdır, böylece her istekte çok sayıda parametrenin iletilmesi gerekebilir. Durum bilgisi altında, cliet bu parametreleri bir kez geçirir ve istemci tarafından yeniden değiştirilene kadar sunucu tarafından korunur.

IMO, API vatansız olmalı, bu da gerçekten hızlı bir şekilde ölçeklendirilmesini sağlar.

İstemci oturumunu istemci tarafında yönetmelisiniz. Bu, her istekle kimlik doğrulama verileri göndermeniz gerektiği anlamına gelir ve muhtemelen, ancak gerekli olmayan, kimlik doğrulama, izinler, vb. Gibi kullanıcı bilgilerine kimlik doğrulama verilerini eşleştiren bir bellek içi önbelleğe sahip olursunuz ...

Bu REST vatansızlığı kısıtı çok önemlidir. Bu kısıtlamayı uygulamadan, sunucu tarafı uygulamanız iyi ölçeklenmeyecektir , çünkü her bir istemci oturumunu korumak Aşil topuğu olacaktır .

Bir RESTful hizmeti geliştirdiğinizde, oturum açabilmek için kullanıcının kimliğinin doğrulanması gerekir. Olası bir seçenek, her kullanıcı eylemi yapmak istediğinizde kullanıcı adını ve şifreyi göndermek olabilir. Bu durumda, sunucu oturum verilerini hiç saklamaz.

Başka bir seçenek de sunucuda bir oturum kimliği oluşturmak ve istemciye göndermek, böylece istemci sunucuya oturum kimliği gönderebilir ve bununla kimlik doğrulaması yapabilir. Bu, her seferinde kullanıcı adı ve şifre göndermekten çok daha güvenlidir, çünkü eğer birisi bu verilere elini tutarsa, kullanıcı adı ve şifre değiştirilene kadar kullanıcıyı taklit edebilir. Oturum kimliğinin bile çalınabileceğini ve kullanıcının bu durumda taklit edileceğini ve haklı olduğunuzu söyleyebilirsiniz. Ancak, bu durumda kullanıcının kimliğine bürünülmesi yalnızca oturum kimliği geçerli olduğunda mümkündür.

RESTful API kullanıcı adını ve parolayı değiştirmek için kullanıcı adı ve parola beklerse, birisi oturum kimliğini kullanarak kullanıcının kimliğine bürünmüş olsa bile, bilgisayar korsanı gerçek kullanıcıyı kilitleyemez.

Bir oturum kimliği, kullanıcıyı tanımlayan ve oturum kimliğine zaman ekleyen bir şeyin tek yönlü kilitlenmesi (şifreleme) ile oluşturulabilir, böylece oturumun sona erme süresi tanımlanabilir.

Sunucu, oturum kimliklerini depolayabilir veya depolamayabilir. Elbette, sunucu oturum kimliğini depolarsa, soruda tanımlanan kriterleri ihlal eder. Bununla birlikte, oturum kimliğinin belirli bir kullanıcı için doğrulanabildiğinden emin olmak önemlidir, bu da oturum kimliğinin saklanmasını gerektirmez. E-posta, kullanıcı kimliği ve favori renk gibi kullanıcıya özgü bazı özel verilerin tek yönlü şifrelemesine sahip olmanın bir yolunu hayal edin, bu ilk düzeydir ve bir şekilde şifrelenmiş dizeye kullanıcı adı tarihini ekler ve yol şifreleme. Sonuç olarak, bir oturum kimliği alındığında, kullanıcının hangi kullanıcı adını talep ettiğini ve oturum süresinin doğru olup olmadığını belirleyebilmek için ikinci seviyenin şifresi çözülebilir. Bu geçerliyse, ilk şifreleme düzeyi, bu şifrelemeyi tekrar yaparak ve dizeyle eşleşip eşleşmediğini kontrol ederek doğrulanabilir. Bunu başarmak için oturum verilerini depolamanız gerekmez.

Tüm konsept farklı ... RESTFul protokolünü uygulamaya çalışıyorsanız oturumları yönetmeniz gerekmez. Bu durumda, her istekte kimlik doğrulama prosedürü yapmak daha iyidir (oysa performans açısından ek bir maliyet söz konusudur - şifre sağlama iyi bir örnek olacaktır. Büyük bir anlaşma değil ...). Oturumlar kullanıyorsanız - yükü birden çok sunucuya nasıl dağıtabilirsiniz? Bahse girerim RESTFul protokolü, oturumları ne olursa olsun ortadan kaldırmak içindir - onlara gerçekten ihtiyacınız yoktur ... Bu yüzden "vatansız" denir. Oturumlar, yalnızca bir istekte bulunulduktan sonra istemci tarafında Çerez dışında bir şey depolayamadığınızda gerekir (örnek olarak eski, Javascript / HTML5 destekli olmayan tarayıcıyı alın). "Tam özellikli" RESTFul istemcisi saklamak genellikle güvenlidirbase64(login:password) Uygulama yüklenene kadar istemci tarafında (bellekte) - uygulama tek ana bilgisayara erişmek için kullanılır ve çerez üçüncü taraf komut dosyaları tarafından ele geçirilemez ...

RESTFul sevices için çerez kimlik doğrulamasını devre dışı bırakmanızı şiddetle tavsiye ederim ... Temel / Özet Kimlik Doğrulama - RESTFul tabanlı hizmetler için yeterli olmalıdır.

REST vatansızdır ve istekler arasında herhangi bir durumu korumaz. İstemci çerezleri / başlıkları, kimlik doğrulama gibi kullanıcı durumunu koruyacak şekilde ayarlanmıştır. Müşteri kullanıcı adı / şifresinin üçüncü bölüm kimlik doğrulama mekanizması - 2. seviye OTP gerneation vb. Tarafından onaylandığını varsayalım. . Şimdi IP gibi kullanıcının belirli bilgileri ya önbellekte tutulur ve bundan sonra listelenen kaynaklar için aynı Ip'den (mac adresi) istek geliyorsa Kullanıcıya izin verilir. Ve önbellek belirli bir süre korunur, bu da zaman geçtikten sonra geçersiz kılınır. Bu nedenle, önbellek kullanılabilir ya da isteklerin s / b bilgisini kalıcı hale getirmek için DB girdileri kullanılabilir.

Buradaki durum bilgisi olmayan, isteğin durum veya meta verilerinin sunucu tarafında tutulmadığı anlamına gelir. Sunucudaki her bir isteği veya kullanıcının durumunu koruyarak performans darboğazlarına yol açar. Sunucudan yalnızca belirli işlemleri gerçekleştirmek için gerekli özniteliklerle birlikte istenir.

Oturumları yönetmeye veya kullanıcılara özel bir deneyim sunmaya gelince, bazı meta verilerin veya kullanıcının olası kullanıcı tercihlerinin, geçmiş istek geçmişinin durumunu tutmayı gerektirir. Bu, çerezler, gizli özellikler veya oturum nesnesinin bakımı ile yapılabilir.

Bu, uygulamadaki kullanıcının durumunu koruyabilir veya takip edebilir.

Bu yardımcı olur umarım!