REST API'nin yerini alacak Websocket API?

Birincil işlevi web yuvaları veya uzun yoklama yoluyla gerçek zamanlı olarak çalışan bir uygulamam var.

Bununla birlikte, sitenin çoğu DİNLENME tarzında yazılmıştır ve bu, gelecekte uygulamalar ve diğer müşteriler için güzeldir. Ancak, tüm site işlevleri için REST'ten uzakta bir websocket API'ye geçmeyi düşünüyorum. Bu, gerçek zamanlı özellikleri sitenin tüm bölümlerine entegre etmemi kolaylaştırır. Bu, uygulama veya mobil istemciler oluşturmayı daha mı zorlaştırır?

Bazı insanların zaten böyle şeyler yaptığını buldum: SocketStream

Buradaki diğer cevapların bir değeri olmadığını söylemem, bazı iyi noktalara işaret ediyorlar. Ancak genel fikir birliğine karşı çıkacağım ve gerçek zamanlı özelliklerden daha fazlası için web yuvalarına geçmenin çok çekici olduğu konusunda sizinle hemfikir olacağım.

Uygulamamı bir RESTful mimarisinden web soketleri aracılığıyla daha çok RPC stiline taşımayı ciddi olarak düşünüyorum. Bu bir "oyuncak uygulama" değil ve sadece gerçek zamanlı özelliklerden bahsetmiyorum, bu yüzden çekincelerim var. Ancak bu rotaya gitmenin birçok faydası görüyorum ve bunun istisnai bir çözüm olabileceğini düşünüyorum.

Planım DNode , SocketIO ve Backbone kullanmak . Bu araçlarla, Backbone modellerim ve koleksiyonlarım, basitçe RPC tarzı bir işlev çağırarak istemci ve sunucuya / istemci ve sunucuya aktarılabilir. Artık REST uç noktalarını yönetmek, nesneleri serileştirmek / seri durumdan çıkarmak ve benzeri şeyler yok. Henüz socketstream ile çalışmadım, ancak incelemeye değer görünüyor.

Bunun iyi bir çözüm olduğunu kesin olarak söyleyebilmem için hala daha uzun bir yolum var ve eminim ki bu her uygulama için en iyi çözüm değildir, ancak bu kombinasyonun son derece güçlü olacağına ikna oldum. Kaynakları önbelleğe alma yeteneğini kaybetmek gibi bazı dezavantajlar olduğunu kabul ediyorum. Ama avantajların onlardan daha ağır basacağını hissediyorum.

Bu tür bir çözümü keşfetme konusundaki ilerlemenizi takip etmek isterim. Herhangi bir github deneyiniz varsa, lütfen beni onlara yönlendirin. Henüz yok, ama umarım yakında.

Aşağıda, topladığım daha sonra okunacak bağlantıların bir listesi bulunmaktadır. Sadece çoğunu gözden geçirdiğim için hepsinin değerli olduğunu garanti edemem. Ama umarım bazıları yardımcı olur.

Express ile Socket.IO'yu kullanma hakkında harika eğitim. İfade oturumlarını socket.io'ya sunar ve kimliği doğrulanmış her kullanıcı için nasıl farklı odalara sahip olunacağını tartışır.

• http://www.danielbaulig.de/socket-ioexpress/

Node.js / socket.io / backbone.js / express / connect / jade / redis ile kimlik doğrulama, Joyent barındırma vb. Hakkında eğitim:

• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Backbone.js ile Pusher'ı kullanma eğitimi (Rails kullanarak):

• http://blog.pusher.com/2011/6/21/backbone-js-now-realtime-with-pusher

İstemcide backbone.js ve sunucuda express, socket.io, dnode ile node.js ile uygulama oluşturun.

• http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
• http://addyosmani.com/blog/building-spas-jquerys-best-friends/
• http://fzysqr.com/2011/02/28/nodechat-js-using-node-js-backbone-js-socket-io-and-redis-to-make-a-real-time-chat-app/
• http://fzysqr.com/2011/03/27/nodechat-js-continued-authentication-profiles-ponies-and-a-meaner-socket-io/

Omurgayı DNode ile Kullanma:

• http://quickleft.com/blog/backbone-without-ajax-part-ii
• http://quickleft.com/blog/backbone-without-ajax-part-1
• http://sorensen.posterous.com/introducing-backbone-redis
• https://github.com/cowboyrushforth/minespotter
• http://amir.unoc.net/how-to-share-backbonejs-models-with-nodejs
• http://hackerne.ws/item?id=2222935
• http://substack.net/posts/24ab8c

HTTP REST ve WebSockets çok farklıdır. HTTP durumsuzdur , bu nedenle web sunucusunun hiçbir şey bilmesi gerekmez ve web tarayıcısında ve proxy'lerde önbelleğe alırsınız. WebSockets kullanıyorsanız, sunucunuz durum bilgisi almaya başlar ve sunucudaki istemciye bir bağlantınız olması gerekir.

İstek-Yanıt iletişimi ve Push

Kullanım WebSockets Gerekirse yalnızca PUSH iletişim desen (sadece geçici çözümler ile), HTTP dahil olmadığını, sunucudan istemciye veri. Diğer istemciler tarafından oluşturulan olayların diğer bağlı istemciler tarafından erişilebilir olması gerekiyorsa, örneğin kullanıcıların diğer istemcilerin davranışlarına göre hareket etmesi gereken oyunlarda PUSH yararlıdır. Veya web siteniz, sunucunun müşteriye her zaman veri gönderdiği bir şeyi izliyorsa, örneğin borsalar (canlı).

Sunucudan verileri PUSH'ye ihtiyaç duymuyorsanız, durum bilgisi olmayan bir HTTP REST sunucusu kullanmak genellikle daha kolaydır. HTTP, basit bir İstek-Yanıt iletişim modeli kullanır.

Tüm site işlevleri için bir WebSocket API'ye geçiş yapmayı düşünüyorum

Hayır. Yapmamalısın. Her iki modeli de desteklerseniz herhangi bir zararı yoktur. Kullanım DİNLENME tek yönlü iletişim / basit istekleri için & WebSocket iki yönlü iletişim için sunucu gerçek zamanlı bildirim göndermek istiyorsanız özellikle.

WebSocket , RESTful HTTP'den daha verimli bir protokoldür, ancak yine de aşağıdaki alanlarda WebSocket üzerinden RESTful HTTP puanları vardır.

1. Oluşturma / Güncelleme / Silme kaynakları HTTP için iyi tanımlanmıştır. Bu işlemleri WebSockets için düşük seviyede uygulamanız gerekir.

2. WebSocket bağlantıları, HTTP bağlantılarının yatay olarak ölçeklendiği tek bir sunucuda dikey olarak ölçeklenir. WebSocket yatay ölçeklendirme için bazı tescilli, standartlara dayalı olmayan çözümler vardır.

3. HTTP, önbelleğe alma, yönlendirme, çoğullama, gzip gibi birçok iyi özellik ile birlikte gelir. Websocket'i seçerseniz, bunlar Websocket üzerine inşa edilmelidir.

4. Arama motoru optimizasyonları, HTTP URL'leri için iyi sonuç verir.

5. Tüm Proxy, DNS, güvenlik duvarları henüz WebSocket trafiğinin tam olarak farkında değil. Bağlantı noktası 80'e izin verirler, ancak önce onu gözetleyerek trafiği kısıtlayabilir.

6. WebSocket ile güvenlik, ya hep ya hiç yaklaşımıdır.

Daha fazla ayrıntı için bu makaleye bir göz atın .

Ana web içeriği sağlama stratejiniz olarak TCP'yi (WebSockets) kullanabildiğim tek sorun, web sitesi mimarinizi ve altyapınızı TCP kullanarak nasıl tasarlayacağınızla ilgili çok az okuma materyali bulunmasıdır.

Yani diğer insanların hatalarından ders alamazsınız ve gelişim daha yavaş olur. Aynı zamanda "denenmiş ve test edilmiş" bir strateji değildir.

Elbette, HTTP'nin tüm avantajlarını da kaybedeceksiniz (Vatansız olmak ve önbelleğe alma daha büyük avantajlardır).

HTTP'nin, web içeriği sunmak için tasarlanmış bir TCP soyutlaması olduğunu unutmayın.

Ve SEO ve arama motorlarının web soketleri yapmadığını unutmayalım. Böylece SEO'yu unutabilirsiniz.

Şahsen ben buna karşı tavsiye ederim çünkü çok fazla risk var.

WS'yi web sitelerine hizmet vermek için kullanmayın, web uygulamalarına hizmet vermek için kullanın

Ancak, bir oyuncağınız veya kişisel bir web siteniz varsa, mutlaka gidin. Deneyin, modern olun. Bir işletme veya şirket için bunu yapma riskini haklı gösteremezsiniz.

Biraz ders aldım (zor yoldan). Ubuntu AWS EC2 bulut hizmetlerinde (güçlü GPU'lar kullanır) çalışan bir numara hesaplama uygulaması yaptım ve ilerlemesini gerçek zamanlı olarak izlemek için bir ön uç yapmak istedim. Gerçek zamanlı verilere ihtiyaç duyması nedeniyle, güncellemeleri göndermek için web yuvalarına ihtiyacım olduğu açıktı.

Bir kavram kanıtıyla başladı ve harika çalıştı. Ancak daha sonra bunu halka açık hale getirmek istediğimizde, kullanıcı oturumu eklememiz gerekti, bu yüzden oturum açma özelliklerine ihtiyacımız vardı. Ve nasıl bakarsanız bakın, web soketinin hangi kullanıcıyla ilgilendiğini bilmesi gerekir, bu yüzden kullanıcıların kimliklerini doğrulamak için web soketlerini kullanma kısayolunu kullandık . Açık görünüyordu ve kullanışlıydı.

Bağlantıları güvenilir kılmak için biraz sessiz kalmak zorunda kaldık. Bazı ucuz websocket eğitimleriyle başladık, ancak uygulamamızın bağlantı kesildiğinde otomatik olarak yeniden bağlanamadığını keşfettik. Soket-io'ya geçtiğimizde bunların hepsi gelişti. Soket-io bir zorunluluktur!

Bütün bunları söyledikten sonra, dürüst olmak gerekirse, bazı harika soket-io özelliklerini kaçırdık. Socket-io'nun sunabileceği çok şey var ve eminim ki ilk tasarımınızda bunu hesaba katarsanız, bundan daha fazlasını elde edebilirsiniz. Bunun aksine, eski websockets'leri socket-io'nun websocket işlevselliği ile değiştirdik ve işte bu kadar. (oda yok, kanal yok, ...) Yeniden tasarım her şeyi daha güçlü hale getirebilirdi. Ama bunun için zamanımız yoktu. Bu, bir sonraki projemiz için hatırlanması gereken bir şey.

Daha sonra daha fazla veriyi (kullanıcı geçmişi, faturalar, işlemler, ...) depolamaya başladık . Hepsini bir AWS dynamodb veritabanında sakladık ve TEKRAR, CRUD işlemlerini ön uçtan arka uca iletmek için socket-io kullandık. Sanırım orada yanlış yola saptık. Bu bir hataydı.

• Çünkü Amazon'un bulut hizmetlerinin (AWS) RESTful uygulamalar için bazı harika yük dengeleme / ölçeklendirme araçları sunduğunu öğrendikten kısa bir süre sonra .
• Artık CRUD işlemlerinin tokalaşmalarını gerçekleştirmek için çok fazla kod yazmamız gerektiği izlenimine sahibiz .
• Son zamanlarda Paypal entegrasyonunu uyguladık. Onu çalıştırmayı başardık. Ancak yine, tüm öğreticiler bunu RESTful API'lerle yapıyor . Örneklerini web soketleriyle uygulamak için yeniden yazmak / yeniden düşünmek zorunda kaldık. Yine de oldukça hızlı çalışmasını sağladık. Ama akışa karşı çıktığımızı hissettiriyor .

Tüm bunları söyledikten sonra, önümüzdeki hafta canlı yayına gireceğiz. Oraya zamanında vardık, her şey çalışıyor. Ve hızlı, ama ölçeklenecek mi?

İkisini de kullanmayı düşünürdüm . Her teknolojinin kendine özgü bir değeri vardır ve tüm çözümlere uyan tek bir çözüm yoktur.

İş ayrımı şu şekilde gerçekleşir:

1. WebSockets , bir oturumun gerekli olduğu sunucu ile iletişim kurmak için bir uygulamanın birincil yöntemi olacaktır . Bu, eski tarayıcılar için gerekli olan birçok korsanlığı ortadan kaldırır (sorun, bunu ortadan kaldıracak eski tarayıcıları desteklemektir)

2. RESTful API , tarayıcı önbelleğinden yararlanan oturum odaklı olmayan (yani kimlik doğrulaması gerekmeyen) GET çağrıları için kullanılır . Buna iyi bir örnek, bir web uygulaması tarafından kullanılan açılır menüler için referans veriler olabilir. Ancak. biraz daha sık değişebilir ...

3. HTML ve Javascript. Bunlar, web uygulamasının kullanıcı arayüzünü oluşturur. Bunlar genellikle bir CDN'ye yerleştirilmekten fayda sağlar.

4. WSDL kullanan Web Hizmetleri , mesaj ve veri aktarımı için iyi tanımlanmış bir standart sağladığı için kurumsal düzeyde ve kurumlar arası iletişimin hala en iyi yoludur . Öncelikle, bunu web hizmeti işleyicinize proxy olarak bir Datapower cihazına aktarırsınız.

Tüm bunlar, halihazırda SSL aracılığıyla güvenli soketler sağlayan HTTP protokolünde gerçekleşir.

Yine de mobil uygulama için, websockets bağlantısı kesilen bir oturuma yeniden bağlanamaz (yakın bağlantıdan sonra websocket'e nasıl yeniden bağlanılır ) ve bunu yönetmek önemsiz değildir. Yani mobil uygulamalar için , hala ediyorum DİNLENME API tavsiye ve yoklamayı .

WebSockets ve REST'i kullanırken dikkat edilmesi gereken bir diğer husus da ölçeklenebilirliktir . WebSocket oturumları hala sunucu tarafından yönetilmektedir. RESTful API, uygun şekilde yapıldığında durum bilgisizdir (bu, yönetilmesi gereken hiçbir sunucu durumu olmadığı anlamına gelir), bu nedenle ölçeklenebilirlik dikey olarak olduğundan yatay olarak (daha ucuz olan) büyüyebilir .

Sunucudan güncelleme almak istiyor muyum?

• Evet: Socket.io
• Hayır: REST

Socket.io'nun dezavantajları şunlardır:

• Ölçeklenebilirlik: WebSockets, açık bağlantılar ve web ölçeğine göre çok farklı bir Ops kurulumu gerektirir.
• Öğrenmek: Öğrenmek için sınırsız zamanım yok. İşlerin yapılması gerekiyor!

Projemde hala Socket.io kullanacağım, ancak REST'in iyi yapacağı temel web formları için kullanmayacağım.

WebSockets (veya uzun yoklama) tabanlı aktarımlar, çoğunlukla sunucu ve istemci arasında (yakın) gerçek zamanlı iletişim için hizmet eder. Sohbet veya bir tür gerçek zamanlı beslemeler veya diğer şeyler gibi bu tür aktarımların gerekli olduğu çok sayıda senaryo olmasına rağmen, bazı web uygulamalarının tüm bölümlerinin sunucuya çift yönlü olarak bağlanması gerekmez.

REST, iyi anlaşılan ve diğer mimarilere göre kendi avantajlarını sunan kaynak tabanlı bir mimaridir. WebSockets, gerçek zamanlı olarak veri akışlarına / beslemelerine daha fazla meyleder; bu, kaynaklar ve beslemeler arasında önceliklendirme veya ayrım yapmak için bir tür sunucu tabanlı mantık oluşturmanızı gerektirir (REST'i kullanmak istemiyorsanız).

Gelecekte, bu aktarımın daha yaygın olacağı ve veri türü / form agnostik teslim şeklinde daha iyi anlaşılacağı / belgeleneceği zaman, gelecekte soket akışı gibi daha fazla WebSockets merkezli çerçeve olacağını varsayıyorum . Ancak, bence bu, REST'in yerini alacağı / değiştirmesi gerektiği anlamına gelmiyor, çünkü çok sayıda kullanım durumu ve senaryosunda mutlaka gerekli olmayan işlevsellik sunuyor.

Bu sorunun en iyi cevabı olan bana kalmış bu blog yazısını belirtmek isterim .

Kısaca EVET

Gönderi, bu tür bir API için en iyi uygulamaları içerir.

Bu iyi bir fikir değil. Standart henüz kesinleşmedi, destek tarayıcılara göre değişiklik gösteriyor, vb. Bunu şimdi yapmak istiyorsanız, son olarak flash veya uzun yoklama vb.'ye geri dönmeniz gerekecek. Gelecekte muhtemelen hala bir çok mantıklı, çünkü sunucunun bağlantıları her bir kullanıcıya açık bırakmayı desteklemesi gerekiyor. Çoğu web sunucusu, bunun yerine, isteklere hızlı bir şekilde yanıt vermede ve bunları olabildiğince çabuk kapatmada mükemmel olacak şekilde tasarlanmıştır. Çok sayıda eşzamanlı bağlantıyla başa çıkmak için işletim sisteminizin bile ayarlanması gerekir (her bağlantı daha fazla geçici bağlantı noktası ve bellek kullanır). Mümkün olduğu kadar sitenin çoğu için REST kullanmaya devam edin.