API Websocket untuk menggantikan REST API?

Saya memiliki aplikasi yang fungsi utamanya bekerja secara real time, melalui websockets atau long polling.

Namun, sebagian besar situs ditulis dengan gaya RESTful, yang bagus untuk aplikasi dan klien lain di masa mendatang. Namun, saya berpikir untuk beralih ke API websocket untuk semua fungsi situs, jauh dari REST. Itu akan memudahkan saya untuk mengintegrasikan fitur waktu nyata ke semua bagian situs. Apakah ini akan mempersulit pembuatan aplikasi atau klien seluler?

Saya menemukan bahwa beberapa orang sudah melakukan hal-hal seperti ini: SocketStream

Bukan untuk mengatakan bahwa jawaban lain di sini tidak pantas, mereka membuat beberapa poin bagus. Tapi saya akan menentang konsensus umum dan setuju dengan Anda bahwa pindah ke websockets untuk lebih dari sekadar fitur waktu nyata sangat menarik.

Saya serius mempertimbangkan untuk memindahkan aplikasi saya dari arsitektur RESTful ke lebih dari gaya RPC melalui websockets. Ini bukan "aplikasi mainan", dan saya tidak hanya berbicara tentang fitur waktu nyata, jadi saya punya reservasi. Tetapi saya melihat banyak manfaat dengan menempuh rute ini dan merasa ini bisa menjadi solusi yang luar biasa.

Rencana saya adalah menggunakan DNode , SocketIO , dan Backbone . Dengan alat ini, model dan koleksi Backbone saya dapat diteruskan dari / ke klien dan server hanya dengan memanggil fungsi RPC-style. Tidak perlu lagi mengelola titik akhir REST, membuat serial / deserialisasi objek, dan sebagainya. Saya belum bekerja dengan socketstream, tapi sepertinya perlu dicoba.

Saya masih harus menempuh jalan panjang sebelum saya dapat secara pasti mengatakan ini adalah solusi yang baik, dan saya yakin ini bukan solusi terbaik untuk setiap aplikasi, tetapi saya yakin bahwa kombinasi ini akan sangat kuat. Saya akui bahwa ada beberapa kekurangan, seperti kehilangan kemampuan untuk menyimpan cache sumber daya. Tapi saya merasa keuntungannya lebih besar daripada mereka.

Saya tertarik untuk mengikuti kemajuan Anda dalam menjelajahi jenis solusi ini. Jika Anda memiliki eksperimen github, tunjukkan saya padanya. Saya belum punya, tapi berharap segera.

Di bawah ini adalah daftar tautan untuk-baca-nanti yang telah saya kumpulkan. Saya tidak dapat menjamin bahwa mereka semua berharga, karena saya hanya membaca sekilas banyak dari mereka. Tapi semoga beberapa akan membantu.

Tutorial hebat menggunakan Socket.IO dengan Express. Ini mengekspos sesi ekspres ke socket.io dan membahas bagaimana memiliki ruang yang berbeda untuk setiap pengguna yang diautentikasi.

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

Tutorial node.js / socket.io / backbone.js / express / connect / jade / redis dengan otentikasi, Joyent hosting, dll:

• 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/

Tutorial menggunakan Pusher dengan Backbone.js (menggunakan Rails):

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

Bangun aplikasi dengan backbone.js pada klien dan node.js dengan express, socket.io, dnode di server.

• 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/

Menggunakan Backbone dengan DNode:

• 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 dan WebSockets sangat berbeda. HTTP tidak memiliki kewarganegaraan , jadi server web tidak perlu tahu apa-apa, dan Anda mendapatkan cache di browser web dan di proxy. Jika Anda menggunakan WebSockets, server Anda menjadi stateful dan Anda harus memiliki koneksi ke klien di server.

Komunikasi Permintaan-Balasan vs Push

Gunakan WebSockets hanya jika Anda perlu PUSH data dari server ke klien, pola komunikasi tersebut tidak disertakan dalam HTTP (hanya dengan solusi). PUSH berguna jika acara yang dibuat oleh klien lain harus tersedia untuk klien lain yang terhubung, misalnya dalam permainan di mana pengguna harus bertindak atas perilaku klien lain. Atau jika situs web Anda memantau sesuatu, di mana server mendorong data ke klien sepanjang waktu, misalnya pasar saham (langsung).

Jika Anda tidak perlu PUSH data dari server, biasanya lebih mudah menggunakan server REST HTTP stateless. HTTP menggunakan pola komunikasi Request-Reply sederhana .

Saya berpikir untuk beralih ke api WebSocket untuk semua fungsi situs

Tidak. Anda tidak harus melakukannya. Tidak ada salahnya jika Anda mendukung kedua model tersebut. Gunakan REST untuk komunikasi satu arah / permintaan sederhana & WebSocket untuk komunikasi dua arah terutama saat server ingin mengirimkan notifikasi secara real time.

WebSocket adalah protokol yang lebih efisien daripada RESTful HTTP tetapi masih skor HTTP RESTful melalui WebSocket di area di bawah ini.

1. Buat / Perbarui / Hapus sumber daya telah ditentukan dengan baik untuk HTTP. Anda harus menerapkan operasi ini pada level rendah untuk WebSockets.

2. Koneksi WebSocket menskalakan secara vertikal di satu server, sementara koneksi HTTP menskalakan secara horizontal. Ada beberapa solusi eksklusif berbasis non standar untuk penskalaan horizontal WebSocket.

3. HTTP hadir dengan banyak fitur bagus seperti caching, routing, multiplexing, gzipping dll. Ini harus dibangun di atas Websocket jika Anda memilih Websocket.

4. Pengoptimalan mesin telusur berfungsi dengan baik untuk URL HTTP.

5. Semua Proxy, DNS, firewall belum sepenuhnya mengetahui lalu lintas WebSocket. Mereka mengizinkan port 80 tetapi mungkin membatasi lalu lintas dengan mengintipnya terlebih dahulu.

6. Keamanan dengan WebSocket adalah pendekatan all-or-nothing.

Lihat artikel ini untuk lebih jelasnya.

Satu-satunya masalah yang saya dapat menggunakan TCP (WebSockets) sebagai strategi pengiriman konten web utama Anda adalah bahwa hanya ada sedikit bahan bacaan di luar sana tentang bagaimana merancang arsitektur dan infrastruktur situs web Anda menggunakan TCP.

Jadi, Anda tidak bisa belajar dari kesalahan orang lain dan perkembangan akan menjadi lebih lambat. Ini juga bukan strategi yang "dicoba dan diuji".

Tentu saja Anda juga akan kehilangan semua keuntungan dari HTTP (Menjadi stateless, dan caching adalah keuntungan yang lebih besar).

Ingat bahwa HTTP adalah abstraksi untuk TCP yang dirancang untuk menyajikan konten web.

Dan jangan lupa bahwa SEO dan mesin pencari tidak membuat websockets. Jadi Anda bisa melupakan SEO.

Secara pribadi saya akan merekomendasikan hal ini karena ada terlalu banyak risiko.

Jangan gunakan WS untuk melayani situs web, gunakan WS untuk melayani aplikasi web

Namun jika Anda memiliki mainan atau situs pribadi dengan segala cara, lakukanlah. Cobalah, jadilah mutakhir. Untuk bisnis atau perusahaan, Anda tidak dapat membenarkan risiko melakukan ini.

Saya belajar sedikit pelajaran (dengan cara yang sulit). Saya membuat aplikasi pengolah angka yang berjalan di layanan cloud Ubuntu AWS EC2 (menggunakan GPU yang kuat), dan saya ingin membuatnya menjadi front-end hanya untuk melihat kemajuannya secara realtime. Karena fakta bahwa itu membutuhkan data waktu nyata, jelas bahwa saya membutuhkan soket web untuk mendorong pembaruan.

Ini dimulai dengan bukti konsep, dan bekerja dengan baik. Tapi kemudian ketika kami ingin membuatnya tersedia untuk umum, kami harus menambahkan sesi pengguna, jadi kami membutuhkan fitur login. Dan tidak peduli bagaimana Anda melihatnya, websocket harus mengetahui pengguna mana yang dihadapinya, jadi kami mengambil jalan pintas menggunakan websockets untuk mengautentikasi pengguna . Tampaknya jelas, dan nyaman.

Kami benar-benar harus meluangkan waktu untuk membuat koneksi dapat diandalkan. Kami memulai dengan beberapa tutorial websocket murah, tetapi menemukan bahwa implementasi kami tidak dapat terhubung kembali secara otomatis ketika koneksi terputus. Itu semua membaik saat kami beralih ke socket-io. Socket-io adalah suatu keharusan!

Karena itu, sejujurnya, saya pikir kami melewatkan beberapa fitur socket-io yang hebat. Socket-io memiliki lebih banyak hal untuk ditawarkan, dan saya yakin, jika Anda memperhitungkannya dalam desain awal Anda, Anda bisa mendapatkan lebih banyak darinya. Sebaliknya, kami hanya mengganti websockets lama dengan fungsionalitas websocket dari socket-io, dan hanya itu. (tidak ada kamar, tidak ada saluran, ...) Desain ulang bisa membuat segalanya lebih kuat. Tapi kami tidak punya waktu untuk itu. Itu adalah sesuatu yang perlu diingat untuk proyek kita selanjutnya.

Selanjutnya kami mulai menyimpan lebih banyak data (riwayat pengguna, faktur, transaksi, ...). Kami menyimpan semuanya dalam database dynamodb AWS, dan LAGI, kami menggunakan socket-io untuk mengomunikasikan operasi CRUD dari front-end ke backend. Saya pikir kami salah belok di sana. Itu adalah sebuah kesalahan.

• Karena tak lama setelah kami mengetahui bahwa layanan cloud Amazon (AWS) menawarkan beberapa alat penyeimbang / penskalaan beban yang hebat untuk aplikasi RESTful .
• Kami mendapat kesan sekarang bahwa kami perlu menulis banyak kode untuk melakukan jabat tangan operasi CRUD.
• Baru-baru ini kami menerapkan integrasi Paypal. Kami berhasil membuatnya bekerja. Tapi sekali lagi, semua tutorial melakukannya dengan RESTful API . Kami harus menulis ulang / memikirkan kembali contoh mereka untuk mengimplementasikannya dengan websockets. Kami membuatnya bekerja cukup cepat. Tapi rasanya kita melawan arus.

Karena itu, kami akan live minggu depan. Kami tiba di sana tepat waktu, semuanya bekerja. Dan itu cepat, tetapi apakah itu akan meningkat?

Saya akan mempertimbangkan untuk menggunakan keduanya . Setiap teknologi memiliki kelebihannya masing-masing dan tidak ada satu solusi yang cocok untuk semua.

Pemisahan pekerjaan berjalan seperti ini:

1. WebSockets akan menjadi metode utama aplikasi untuk berkomunikasi dengan server di mana sesi diperlukan. Ini menghilangkan banyak peretasan yang diperlukan untuk peramban lama (masalahnya adalah dukungan untuk peramban lama yang akan menghilangkan ini)

2. RESTful API digunakan untuk panggilan GET yang tidak berorientasi pada sesi (misalnya, tidak diperlukan otentikasi) yang memanfaatkan cache browser. Contoh yang bagus dari ini adalah data referensi untuk drop down yang digunakan oleh aplikasi web. Namun. dapat berubah sedikit lebih sering daripada ...

3. HTML dan Javascript. Ini terdiri dari UI aplikasi web. Ini umumnya akan menguntungkan ditempatkan pada CDN.

4. Layanan Web yang menggunakan WSDL masih merupakan cara terbaik untuk komunikasi antar-perusahaan dan tingkat perusahaan karena WSDL menyediakan standar yang ditentukan dengan baik untuk penyampaian pesan dan data. Terutama Anda akan memindahkan ini ke perangkat Datapower ke proxy ke penangan layanan web Anda.

Semua ini terjadi pada protokol HTTP yang sudah memberikan penggunaan soket aman melalui SSL.

Untuk aplikasi seluler, websockets tidak dapat menyambungkan kembali ke sesi terputus ( Cara menyambungkan kembali ke websocket setelah koneksi dekat ) dan mengelola itu tidak sepele. Jadi untuk aplikasi seluler , saya tetap akan merekomendasikan REST API dan polling.

Hal lain yang harus diperhatikan saat menggunakan WebSockets vs REST adalah skalabilitas . Sesi WebSocket masih dikelola oleh server. RESTful API bila dilakukan dengan benar bersifat stateless (yang berarti tidak ada status server yang perlu dikelola), sehingga skalabilitas dapat tumbuh secara horizontal (yang lebih murah) daripada secara vertikal .

Apakah saya ingin pembaruan dari server?

• Ya: Socket.io
• Tidak ada istirahat

Kerugian dari Socket.io adalah:

• Skalabilitas: WebSockets memerlukan koneksi terbuka dan penyiapan Ops yang jauh berbeda dengan skala web.
• Learnin: Saya tidak punya waktu tak terbatas untuk belajar saya. Hal-hal harus diselesaikan!

Saya masih akan menggunakan Socket.io dalam proyek saya, tetapi tidak untuk formulir web dasar yang akan dilakukan REST dengan baik.

Transport berbasis WebSockets (atau long polling) sebagian besar berfungsi untuk (hampir) komunikasi waktu nyata antara server dan klien. Meskipun ada banyak skenario di mana jenis transportasi ini diperlukan, seperti obrolan atau semacam umpan waktu nyata atau hal-hal lain, tidak semua bagian dari beberapa aplikasi web perlu dihubungkan secara dua arah dengan server.

REST adalah arsitektur berbasis sumber daya yang dipahami dengan baik dan menawarkan keunggulannya sendiri dibandingkan arsitektur lain. WebSockets lebih condong ke aliran / umpan data secara real-time yang mengharuskan Anda membuat semacam logika berbasis server untuk memprioritaskan atau membedakan antara sumber daya dan umpan (jika Anda tidak ingin menggunakan REST).

Saya berasumsi bahwa pada akhirnya akan ada lebih banyak kerangka kerja WebSockets sentris seperti socketstream di masa depan ketika pengangkutan ini akan lebih luas dan lebih dipahami / didokumentasikan dalam bentuk tipe data / bentuk pengiriman agnostik. Namun, menurut saya, ini tidak berarti bahwa itu akan / harus menggantikan REST hanya karena ia menawarkan fungsionalitas yang tidak selalu diperlukan dalam banyak kasus dan skenario penggunaan.

Saya ingin menunjukkan entri blog ini yang menurut saya, jawaban terbaik untuk pertanyaan ini.

Singkatnya, YA

Postingan tersebut berisi semua praktik terbaik untuk jenis API semacam itu.

Itu bukan ide yang bagus. Standar ini bahkan belum diselesaikan, dukungan bervariasi di semua browser, dll. Jika Anda ingin melakukan ini sekarang, Anda harus kembali ke flash atau polling yang lama, dll. Di masa mendatang mungkin masih tidak akan membuat masuk akal, karena server harus mendukung meninggalkan koneksi terbuka untuk setiap pengguna. Sebagian besar server web dirancang untuk unggul dalam menanggapi permintaan dengan cepat dan menutupnya secepat mungkin. Bahkan sistem operasi Anda harus disetel untuk menangani sejumlah besar koneksi simultan (setiap koneksi menggunakan lebih banyak port dan memori sementara). Tetap gunakan REST untuk situs sebanyak yang Anda bisa.