Apakah ini "anti-pola" dan haruskah saya berhenti menggunakannya atau apakah ini desain yang cerdas?


10

Saya pada dasarnya telah melakukan hal-hal berikut ketika membuat layanan REST:

  1. HTML diminta
  2. layanan mengembalikan halaman web yang diinginkan tetapi tanpa "sumber daya" yang diminta, mis. data
  3. halaman web berisi JavaScript yang mengeluarkan permintaan AJAX ke layanan yang sama (tipe konten berbeda)
  4. layanan kemudian mengembalikan data aktual (JSON) dan halaman menampilkannya

Di satu sisi tampaknya tidak efisien (2 permintaan) tetapi kemudian saya menggunakan ini, "kinerja tidak menjadi perhatian", yang berarti aplikasi internal traffic rendah dan situs web sederhana dan memuat cepat.

Alasan saya akhirnya dengan ini adalah bahwa halaman web kemudian dapat menjadi hampir murni Html + JavaScript dan hampir tidak ada hal-hal sisi server diperlukan, terutama tidak ada loop, untuk membuat tabel dan hal-hal seperti itu (yang saya pikir sangat jelek dibandingkan dengan hal-hal seperti slickgrid), misalnya pemisahan data dan tampilan.

Sekarang sebelum saya menggunakan ini, apakah ini ide yang bagus atau haruskah saya berhenti melakukannya?


2
Jika Anda ingin menghabiskan lebih banyak waktu dengan orang yang Anda cintai, dan Anda ingin memiliki waktu luang untuk menikmati hobi, atau mengejar tujuan pribadi, maka demi Tuhan: Jangan memprogram aplikasi seperti itu! Tetapi jika Anda suka menginap larut malam dan akhir pekan di kantor dengan mempertahankan banyak kode "pintar" maka sesuaikan dengan keinginan Anda.
Tulains Córdova

3
Bisakah Anda menguraikan secara spesifik apa yang menurut Anda buruk? Konteks: Ini bukan binatang 10 Mio LOC yang kritis terhadap bisnis. Ini lebih seperti <5000 LOC dan tidak masalah jika tidak bekerja selama beberapa hari. Ya, itu belum saya harus lakukan hal-hal buruk, maka elaborte apa yang Anda anggap sangat buruk.
beginner_

@ begginer_ Setiap perangkat lunak mulai dari yang kecil. Apa yang Anda gambarkan sebagai Rube Goldberg Machine: palu hit man, man drop biskuit, parrot grab biskuit dan vas miring, dll.
Tulains Córdova

Alasan ini dilakukan adalah sering untuk meningkatkan kinerja, di mana pengambilan data dapat dilakukan dengan beberapa permintaan simultan ke server yang mungkin berbeda. Sepertinya ini tidak berlaku untuk Anda.
user16764

Bagaimana Anda menggunakan layanan ini dari klien seperti skrip, atau dari curl? Hal-hal itu tidak memiliki penerjemah javascript. Apakah ini untuk layanan khusus browser?
Bryan Oakley

Jawaban:


17

Jika Anda meminta sumber daya dan tidak mengandung data, maka itu bukan layanan REST. Layanan yang menyediakan data aktual di json mungkin, tetapi bagian HTML tidak. Untuk aplikasi web itu tidak masalah.

Teknik ini berfungsi, tetapi Anda harus menyadari keterbatasannya:

  1. Mesin pencari tidak mengartikan JavaScript, jadi situs yang diimplementasikan seperti itu tidak akan dapat diindeks oleh Google dan sejenisnya. Untuk aplikasi internal itu tidak masalah, bagi publik yang menghadapinya itu akan jadi masalah besar.
  2. Pengguna dengan kebutuhan khusus (seperti mereka yang menggunakan terminal Braille) menggunakan browser khusus yang agak terbatas dan mungkin tidak menafsirkan JavaScript dengan benar.

Saya juga akan mencatat bahwa kode yang menghasilkan HTML pada dasarnya sama apakah menjalankan sisi server atau sisi klien. Anda memiliki pilihan yang jauh lebih besar dari kedua bahasa dan kerangka kerja di sisi server dan saya yakin ada beberapa padanan slickgrid juga.

Anda dapat, dan harus, tetap mempertahankan pemisahan data dan tampilan di sisi server. Sistem template dapat, dan seharusnya, cukup mengambil data sebagai struktur data atau bahkan json (terutama jika layanan sebenarnya dalam bahasa yang berbeda dari sistem template) dan hanya perlu memperluas template dengan data tersebut.

Dan tidak, saya tidak berpikir tentang PHP; itu adalah sistem template yang paling tidak mampu di luar sana (meskipun ada beberapa yang lebih baik dibangun di atasnya). Saya berpikir Genshi atau XSLT atau sesuatu yang lebih maju yang menyediakan widget web.


Saya menulis klien besar dalam JavaScript, yang melakukan hal ini dengan tepat. Tapi itu mungkin ide yang buruk untuk situs web normal.
K ..

Mengapa tidak REST?
dagnelies

1
Jika Anda membedakan antara "data" yang membentuk aplikasi (HTML, JS, CSS, dll) dan "data" yang ditampilkan aplikasi (JSON) bagian JSON adalah REST, tetapi bagian yang memuat "kode" tidak t. Jika Anda melihat semuanya lebih abstrak, keduanya.
K ..

2

Tidak ada yang salah dengan melakukan ini, selama Anda memastikan untuk menyusun kode Anda dengan bersih. Anda bahkan dapat menyajikan konten statis dari mis. Apache daripada layanan web Anda.


2
Apache adalah jumlah berlebihan untuk konten statis. Ada banyak server yang lebih cepat. Paling populer sepertinya adalah Nginx .
Jan Hudec

5
Itu contoh, tidak lebih.
Steven Schlansker

2

Ini praktik yang bagus. Dan itu dilakukan sepanjang waktu, althogugh seperti @JanHudec tunjukkan, menyebutnya layanan REST salah. Tetapi banyak situs web melakukan hal ini tepat untuk alasan yang Anda tunjukkan.


1
... dan alasan besar yang banyak melakukannya adalah karena interaksi data melalui layanan / JSON pula , jadi kemungkinan yang lebih baik untuk menangani semua interaksi data Anda dengan cara yang sama. (yaitu jika Anda menggunakan AJAX untuk me-refresh tabel ... Anda juga harus menggunakannya untuk membangun tabel di tempat pertama.)
Chad Thompson

@ChadThompson Ya, saya menemukan banyak waktu jika saya tidak membangun hal-hal seperti ini di tempat pertama, di suatu tempat di ujung baris saya akan mendapatkan permintaan fitur untuk secara dinamis memperbarui halaman berdasarkan pada klien melakukan sesuatu - yang berarti bahwa implementasi sederhana sekarang mengarah ke klien dan server mengetahui cara membangun halaman. Lebih mudah untuk hanya membangunnya di klien.
Tacroy

1

Saya tidak akan menyebutnya anti-pola, apa yang Anda gambarkan adalah lebih atau kurang klien yang gemuk , tidak sama sekali berbeda dengan layanan seperti Trello. Tanggung jawab awal server adalah mengirim DOM dan sumber daya apa pun yang diperlukan untuk membuat klien bekerja. Saya telah mengerjakan proyek serupa dalam otomatisasi pusat data dan pemantauan jaringan.

Klien memulai sebagai DOM yang jarang, menarik beberapa data melalui XHR (kadang-kadang melalui JSONP) dan akhirnya melekatkan dirinya ke server socket. Contoh yang bahkan lebih mendasar adalah aplikasi obrolan.

Satu-satunya alasan untuk tidak melakukannya adalah sangat sulit untuk memperbaikinya. Jika Anda merasa nyaman dengan pemrograman fungsional asinkron dan semua balapan dan tantangan lain yang dapat dihadirkannya, maka Anda tidak akan kesulitan mempertahankannya. Lebih penting lagi, Anda tidak akan kesulitan menulisnya sehingga orang lain akhirnya bisa memeliharanya.

Jika pemikiran untuk menambahkan lebih banyak fitur mulai menakuti Anda, atau Anda mulai menemukan bahwa debugging adalah mimpi buruk, maka Anda mungkin ingin mempertimbangkan metode lain dalam produksi saat Anda terus bereksperimen dan belajar.

Ini adalah desain yang valid selama Anda tidak menggali lubang untuk diri sendiri. Jika Anda memiliki sekumpulan JS acak di mana-mana alih-alih antarmuka yang bersih, maka Anda mungkin ingin memberi faktor ulang atau mengerjakan proyek secara berbeda. Sebagian besar fungsi Anda yang ditetapkan untuk dijalankan setelah semua sumber daya dimuat harus anonim dan dimasukkan dari antarmuka yang bersih. Jika tidak, Anda mungkin menuju masalah.


Apa yang Anda maksud dengan "JS acak"? Dalam kasus saya apa yang Anda gambarkan di atas jauh lebih kompleks dari yang saya miliki (beberapa kolom input dan tabel (slickgrid) atau tab jquery ui). Hanya itu saja. Sekitar 200 LOC per halaman.
beginner_

0

seperti yang dikatakan @Jan Hudec, pendekatan Anda pasti tidak bisa disebut REST. Meskipun bagian di mana permintaan klien untuk sumber daya bisa. Lebih baik jika klien menangani bagian presentasi, seperti backbonehalnya. Ini berkomunikasi dengan server REST untuk sumber daya dan menampilkan mereka menggunakan views.


0

Ini mungkin anti-pola, tapi saya pikir itu juga masa depan aplikasi web. Alih-alih mucking tentang dengan JavaScript, Anda harus menggunakan setidaknya perpustakaan templating. Solusi yang lebih baik adalah kerangka kerja MVC sisi klien seperti AngularJS (yang kebetulan saya gunakan sekarang).

Untuk beberapa referensi lainnya, berikut adalah posting blog populer yang membandingkan beberapa kerangka kerja, dan inilah situs yang mengimplementasikan program yang sama menggunakan banyak kerangka kerja.

Juga: Komentar Jan Hudec tentang interaksi mesin pencari dan pembaca layar adalah valid. Jika Anda bekerja di situs eCommerce (di mana pagerank penting), maka Anda mungkin tidak ingin menggunakan kerangka kerja sisi klien. Tetapi untuk aplikasi internal, ini biasanya bukan masalah.


Terima kasih AngularJS. Tapi saya pikir untuk kebutuhan saya saat ini terlalu banyak.
beginner_

0

Apa yang kamu lakukan terdengar bagus! Namun jika respons json Anda mengandung HTML apa pun maka Anda membuang-buang waktu.

Poin lain adalah klien bodoh Anda mungkin harus mendapatkan data jsonnya dari proyek yang berbeda. Anda harus bertujuan untuk pemisahan yang tepat antara klien dan layanan maka Anda akan memiliki layanan tenang yang tepat

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.