Apa yang sebenarnya salah dengan endpoint yang mengembalikan HTML daripada data JSON?


77

Ketika saya pertama kali mulai belajar PHP (sekitar 5 atau 6 tahun yang lalu) saya belajar tentang Ajax , dan saya melalui "fase-fase":

  1. Server Anda mengembalikan data HTML dan Anda memasukkannya ke dalam DHT's innerHTML
  2. Anda belajar tentang format transfer data seperti XML (dan katakan "oooh jadi ITULAH untuk apa itu digunakan) dan kemudian JSON.
  3. Anda mengembalikan JSON dan membangun UI Anda menggunakan kode JavaScript vanilla
  4. Anda pindah ke jQuery
  5. Anda belajar tentang API, header, kode status HTTP, REST , CORS dan Bootstrap
  6. Anda belajar SPA , dan kerangka kerja frontend ( React , Vue.js , dan AngularJS ) dan standar API JSON.
  7. Anda menerima beberapa kode warisan perusahaan dan setelah memeriksanya, temukan bahwa mereka melakukan apa yang dijelaskan pada langkah 1.

Ketika saya bekerja dengan basis kode warisan ini, saya bahkan tidak menganggap itu bisa mengembalikan HTML (maksud saya, kami adalah profesional sekarang, kan?), Jadi saya kesulitan mencari titik akhir JSON yang mengembalikan data yang panggilan Ajax mengisi. Baru setelah saya bertanya kepada "programmer" dia mengatakan kepada saya bahwa itu mengembalikan HTML dan ditambahkan langsung ke DOM dengan innerHTML.

Tentu saja, ini sulit diterima. Saya mulai memikirkan cara untuk memperbaiki ini menjadi titik akhir JSON, berpikir tentang unit yang menguji titik akhir dan seterusnya. Namun, basis kode ini tidak memiliki tes. Bukan satu pun. Dan itu lebih dari 200 ribu baris. Tentu saja salah satu tugas saya termasuk mengusulkan pendekatan untuk menguji semuanya, tetapi saat ini kami belum mengatasinya.

Jadi saya di mana saja, di sudut, bertanya-tanya: jika kita tidak memiliki tes apa pun, jadi kita tidak punya alasan khusus untuk membuat titik akhir JSON ini (karena itu tidak "dapat digunakan kembali": itu benar-benar mengembalikan data yang hanya cocok pada bagian dari aplikasi, tapi saya pikir ini sudah tersirat karena ... mengembalikan data HTML).

Apa sebenarnya yang salah dengan melakukan ini?



3
Juga terkait: stackoverflow.com/questions/1284381/… <- Jawaban yang sangat bagus di SO.
Machado

73
Server yang menggunakan Protokol Transfer HyperText yang mengembalikan HyperText ?! Menyeramkan!
Andy

3
@Andy Jujur saja, sebenarnya Generic Message Transfer Protocol: tidak ada yang spesifik untuk mentransfer hypertext, berlawanan dengan FTP, yang banyak berbicara tentang hal-hal khusus untuk file dan direktori.
Joker_vD

4
@ Joker_vD Saya belum pernah mendengar tentang protokol yang disebut GMTP. Sementara hal-hal telah berkembang dan Anda dapat mengirim jenis konten lain melalui HTTP, itu bukan maksud aslinya. Maksud saya adalah hanya karena Anda dapat mengirim konten lain selain HyperText menggunakan HTTP, tampaknya konyol untuk menyarankan bahwa tidak valid lagi untuk menggunakannya untuk tujuan aslinya.
Andy

Jawaban:


114

Apa yang sebenarnya salah dengan endpoint yang mengembalikan HTML daripada data JSON?

Tidak ada apa-apa. Setiap aplikasi memiliki persyaratan yang berbeda, dan mungkin aplikasi Anda tidak dirancang untuk menjadi SPA.

Mungkin kerangka kerja indah yang Anda kutip (Angular, Vue, React, dll ...) tidak tersedia pada waktu pengembangan, atau tidak "disetujui" untuk digunakan dalam organisasi Anda.

Saya akan memberi tahu Anda ini: titik akhir yang mengembalikan HTML mengurangi ketergantungan Anda pada pustaka JavaScript dan mengurangi beban pada browser pengguna karena tidak perlu menafsirkan / mengeksekusi kode JS untuk membuat objek DOM - HTML sudah ada di sana, itu hanya masalah penguraian elemen dan rendering mereka. Tentu saja, ini berarti kita berbicara tentang jumlah data yang masuk akal. 10 megabita data HTML tidak masuk akal.

Tetapi karena tidak ada yang salah dengan mengembalikan HTML, apa yang Anda kehilangan dengan tidak menggunakan JSON / XML pada dasarnya adalah kemungkinan menggunakan titik akhir Anda sebagai API. Dan inilah pertanyaan terbesar: apakah itu benar-benar perlu menjadi API?

Terkait: Apakah boleh mengembalikan HTML dari JSON API?


4
Saya akan mengambil langkah mundur sebelum mengatakan itu hanya "hanya preferensi". Ada beberapa "masalah besar" keputusan yang harus Anda buat: Apakah itu API atau tidak, apakah saya memiliki perpustakaan yang tepat untuk bekerja dengan ini sebagai data JSON pada klien, jenis klien apa yang akan saya dukung (browser tanpa Javascript, untuk contoh), berapa volume vs waktu CPU yang saya miliki untuk digunakan, strategi mana yang akan
Machado

7
"Itu tidak perlu menafsirkan kode JS untuk membuat objek DOM - objek DOM sudah ada, itu hanya masalah rendering mereka" - well, HTML sudah ada di sana (setelah tiba di atas kabel). Browser harus menguraikan HTML dan membuat objek DOM darinya.
Paul D. Waite

7
Tidak ada alasan mengapa HTML tidak dapat bertindak sebagai API. Nol. Tidak ada Bahkan, HAL + JSON dan HAL + XML memiliki kemiripan yang mencolok dengan HTML. Berikut ini adalah pembicaraan yang bagus tentang REST. Bagian yang relevan tentang pengembalian HTML dari titik akhir mendekati akhir. youtu.be/pspy1H6A3FM Secara pribadi, saya membuat semua titik akhir saya mengembalikan json dan HTML. Jika Anda menulis layanan yang dapat ditemukan, membuatnya sangat mudah untuk menjelajahinya di ... terkesiap ... browser.
RubberDuck

4
Karena benar-benar menyebalkan untuk mengekstrak data yang benar-benar Anda pedulikan untuk mencoba menggunakannya dengan cara baru?
DeadMG

4
Melayani HTML melalui HTTP? Apa ini? Sebuah situs?
Semut

50

JSON dan HTML memenuhi dua tujuan semantik yang berbeda.

Jika Anda mengisi halaman web dengan data, gunakan JSON. Jika Anda membangun halaman web dari bagian halaman web, gunakan HTML.

Mereka mungkin terdengar seperti mereka hal yang sama, tetapi sebenarnya tidak sama. Untuk satu hal, ketika Anda membangun sebagian dari halaman web menggunakan HTML yang dikembalikan oleh server, Anda bekerja di sisi server. Saat Anda mengikat data ke halaman web, Anda bekerja di sisi klien.

Selain itu, Anda harus berhati-hati dengan HTML untuk tidak terikat erat pada halaman tertentu. Inti dari merender sebagian halaman dengan cara ini adalah agar sebagian dapat digunakan kembali, dan jika Anda membuat parsial terlalu spesifik, itu tidak akan dikomposisi ke halaman lain. JSON tidak memiliki masalah ini, karena itu hanya data, bukan struktur halaman web.


1
"Untuk satu hal, ketika Anda membangun sebagian dari halaman web menggunakan HTML, Anda bekerja di sisi server." Mengapa? Saya tidak melihat alasan mengapa ini harus terjadi. Itu hanya jelas benar untuk memuat halaman awal dan bisa dibilang, bahkan saat itu karena klien dapat membuat permintaan untuk data yang dibutuhkan.
DeadMG

3
@DeadMG Seharusnya mengatakan "ketika Anda membangun sebagian dari halaman web menggunakan HTML yang dikembalikan oleh server" (sebagai lawan menggunakan JSON yang dikembalikan oleh server)
user253751

Memang, tetapi karena ada sedikit motivasi untuk itu menjadi masalahnya, saya tidak mengerti intinya.
DeadMG

6
@DeadMG Sedikit motivasi untuk apa yang akan terjadi? Agar server mengembalikan HTML? Itulah arti sebenarnya dari seluruh pertanyaan SE ini.
user253751

Pertanyaannya adalah apakah Anda harus mengembalikan HTML atau tidak. Jelas bahwa respons awal harus berupa HTML tetapi tidak ada alasan yang jelas mengapa API lain harus mengembalikan HTML.
DeadMG

22

Masalah utama adalah bahwa itu secara ketat memasangkan server ke klien, yang harus mengetahui struktur HTML. Ini juga membuat titik akhir lebih sulit untuk digunakan kembali dengan cara baru atau aplikasi baru.

Mengembalikan data biasa dan membiarkan klien merendernya mengurangi kopling dan meningkatkan fleksibilitas dan testability - Anda dapat menjalankan tes unit pada klien untuk data tiruan, dan menjalankan tes unit pada server untuk menguji data yang diinginkan.


11
HTML bisa dibuat cukup umum. Anda dapat mengembalikan daftar berpoin, misalnya, dan memasukkannya ke dalam div, di mana ia akan dikenakan styling oleh CSS yang berlaku.
Robert Harvey

10
Itu tidak terlalu berguna jika saya perlu memasukkannya ke dalam rentang waktu ini. Atau render di aplikasi lain yang tidak dirender dalam HTML.
DeadMG

2
Saya akan ulangi seperti yang akan selalu menulis HTML, dan bentuk HTML itu harus selalu benar-benar konsisten di semua penggunaan, yang bukan jaminan yang sangat membantu. Misalnya, di aplikasi kami, kami memiliki daftar, tetapi kami sebenarnya tidak menggunakan uldan lisebaliknya berubah untuk menjadikannya masing-masing div(tidak ingat mengapa). Akan menjadi rumit jika server mengembalikan banyak HTML dengan uls dan lis di dalamnya.
DeadMG

2
Tampaknya tidak ada gunanya untuk mendapatkan jaminan di tempat pertama ketika Anda bisa mengembalikan data dan membiarkan klien merendernya sebagai HTML sesuai keinginan (jika itu akan membuatnya sama sekali)
DeadMG

1
Satu-satunya skenario yang saya bisa lihat di mana mengembalikan HTML lebih disukai adalah jika klien tidak memiliki cukup sumber daya untuk melakukan rendering itu sendiri.
DeadMG

14

Saya pikir Anda memilikinya sedikit mundur. Kamu bilang:

kami tidak memiliki tes apa pun, jadi kami tidak memiliki alasan khusus untuk membuat titik akhir JSON ini

Alasan untuk menggunakan titik akhir yang tepat adalah agar Anda bisa mengujinya. Saya akan mengatakan bahwa tidak memiliki tes adalah alasan yang sangat baik untuk mulai menulis. Yaitu, jika ada logika yang cocok untuk diuji.

200k baris kode banyak yang harus diperbaiki dan mungkin sulit dipertahankan. Memecahkan beberapa titik akhir dan mengujinya mungkin merupakan tempat yang baik untuk memulai.

Alasan lain mungkin untuk memisahkan server dari klien. Jika, di masa depan yang jauh, desain aplikasi atau perubahan tata letak, lebih mudah untuk bekerja dengan format data yang tepat daripada output HTML. Di dunia yang ideal, Anda hanya perlu mengubah klien dan tidak menyentuh server sama sekali.


Poin tentang perubahan tata letak terdengar lebih seperti kebutuhan untuk memisahkan templat dari data yang mendasarinya, tetapi tidak ada alasan templat tersebut harus ada di klien. Memang, ada banyak alasan bagi mereka untuk tidak menjadi, misalnya Anda tidak dapat memutuskan untuk menyembunyikan data dari klien jika rendering Anda ada di klien. Sebagian HTML dapat dikuliti kembali jika dihasilkan oleh sistem templating yang sama dengan halaman HTML lengkap.
IMSoP

6

Ada 3 cara (setidaknya?) Untuk membangun halaman web:

  • Hasilkan seluruh sisi server halaman.
  • Kembalikan halaman tulang kosong dari server plus kode (JavaScript), dan minta halaman mengambil datanya dan render ke sisi klien HTML.
  • Kembalikan sebagian halaman plus kode, dan minta kode untuk mengambil blok HTML yang telah disediakan sebelumnya sehingga dapat dimasukkan ke halaman.

Yang pertama baik-baik saja. Yang kedua juga baik-baik saja. Itu yang terakhir itulah masalahnya.

Alasannya sederhana: Anda sekarang telah membagi konstruksi halaman HTML menjadi bagian-bagian yang benar-benar terputus. Masalahnya adalah salah satu pemeliharaan. Sekarang Anda memiliki dua entitas terpisah yang bertugas mengelola detail UI. Jadi, Anda harus menyimpan CSS dan detail serupa lainnya dalam sinkronisasi antara dua bagian yang terpisah. Anda mengubah lebar bilah samping? Bagus. Sekarang fragmen HTML yang kembali menyebabkan pengguliran horizontal karena asumsi tentang lebar bilah samping tidak lagi berlaku. Anda mengubah warna latar belakang untuk blok itu? Hebat, sekarang benturan warna font fragmen HTML Anda karena diasumsikan warna latar yang berbeda dan seseorang lupa untuk menguji titik akhir itu.

Intinya adalah bahwa Anda sekarang telah membagi pengetahuan yang harus dipusatkan di satu tempat (yaitu logika presentasi), dan ini membuatnya lebih sulit untuk memastikan semua bagian cocok bersama dengan benar. Dengan menggunakan JSON API, Anda bisa menyimpan semua logika itu hanya di ujung depan, atau Anda bisa menyimpan semuanya di templat sisi server jika Anda merender data ke dalam HTML untuk memulai. Ini tentang menjaga pengetahuan / logika presentasi di satu tempat, sehingga dapat dikelola secara konsisten dan sebagai bagian dari proses tunggal. HTML / CSS / JS cukup sulit untuk tetap lurus tanpa memecahnya menjadi banyak potongan kecil.

API JSON juga memiliki manfaat tambahan untuk membuat data tersedia sepenuhnya terlepas dari logika presentasi. Ini memungkinkan banyak penyaji yang berbeda , seperti aplikasi seluler dan halaman web, untuk menggunakan data yang sama. Secara khusus, ini memungkinkan mengkonsumsi data tanpa browser (seperti aplikasi seluler atau pekerjaan cron malam); konsumen ini bahkan mungkin tidak dapat menguraikan HTML. (Ini tentu saja harus bergantung pada memiliki situasi di mana data adalah sama antara konsumen yang berbeda, atau satu dapat menggunakan subset yang lain.) Apakah Anda memerlukan kemampuan ini tergantung pada persyaratan aplikasi khusus Anda, meskipun, sambil mengelola presentasi Anda Logikanya perlu bagaimanapun juga. Saya akan mengatakan bahwa jika Anda menerapkannya di muka, Anda akan lebih siap untuk pertumbuhan di masa depan.


2
Saya benar-benar berpikir menghindari logika tampilan duplikat bisa menjadi alasan yang baik untuk membuat fragmen halaman HTML: jika Anda membuat bagian dari halaman di server (mis. Tajuk dan tata letak dasar), lalu buat bagian lain berdasarkan data JSON pada klien, Anda memiliki dua set template yang berbeda. Merender parsial pada server memindahkan logika ini kembali ke lapisan presentasi pusat Anda, yang dapat menggunakan templat yang sama untuk membuat komponen individu seperti yang akan terjadi jika itu merakit seluruh halaman secara statis.
IMSoP

1
kaulah satu-satunya yang menyebutkan ponsel, aku ingin memberimu seribu upvotes untuk itu
Lovis

1
@IMSoP Jika Anda membutuhkan halaman dinamis , maka Anda harus memiliki logika front end. Jika Anda masih membuat sisi server fragmen, sekarang Anda harus memastikan asumsi ujung depan cocok dengan prasyarat server membangun fragmen. Anda tidak dapat memutus ketergantungan itu. Menyimpan pengetahuan itu dalam sinkronisasi lebih sulit jika dibagi menjadi sistem yang benar-benar terbagi. Jika Anda hanya membuat di ujung depan, asumsi-asumsi itu terpusat. Saya pikir saya juga akan menghindari pencampuran ujung depan yang dinamis dengan keadaan awal dalam templat sisi server; "bootstrap" untuk memulai ujung depan lebih sederhana.
jpmc26

4

Saya akan mengatakan tidak ada yang salah dengan server mengembalikan fragmen HTML dan UI menugaskannya ke .innerHTML dari beberapa elemen. Ini, menurut saya, cara termudah untuk mengembangkan kode JavaScript asinkron. Manfaatnya adalah sesedikit mungkin dilakukan dengan menggunakan JavaScript dan sebanyak mungkin dilakukan dalam lingkungan back-end yang terkontrol. Ingatlah bahwa dukungan JavaScript di browser bervariasi tetapi back-end Anda selalu memiliki versi yang sama dari komponen back-end, yang berarti bahwa melakukan sebanyak mungkin di back-end akan berarti sesedikit mungkin versi tidak kompatibel.

Sekarang, terkadang Anda menginginkan lebih dari sekadar fragmen HTML. Misalnya, kode status dan fragmen HTML. Kemudian Anda bisa menggunakan objek JSON yang memiliki dua anggota, statusCode dan HTML yang kedua dapat ditugaskan ke .innerHTML dari beberapa elemen setelah memeriksa statusCode. Jadi, menggunakan JSON dan menggunakan innerHTML sama sekali bukan alternatif pendekatan eksklusif; mereka bisa digunakan bersama.

Dengan menggunakan JSON Anda bahkan dapat memiliki beberapa fragmen HTML dalam respons yang sama yang ditugaskan ke .innerHTML dari beberapa elemen.

Singkatnya: gunakan .innerHTML. Itu membuat kode Anda kompatibel dengan versi browser sebanyak mungkin. Jika membutuhkan lebih banyak, gunakan JSON dan .innerHTML bersamaan. Hindari XML.


4

Pada prinsipnya tidak ada yang salah . Pertanyaannya adalah: Apa yang ingin Anda capai?

JSON sangat cocok untuk mengirim data. Jika Anda mengirim HTML dan mengharapkan klien untuk mengekstrak data dari HTML, itu sampah.

Di sisi lain, jika Anda ingin mentransmisikan HMTL yang akan dirender sebagai HTML, kemudian kirimkan sebagai HTML - alih-alih mengemas HTML menjadi string, mengubah string menjadi JSON, mentransmisikan JSON, mendekodekannya di sisi lain , mendapatkan string, dan mengekstraksi HTML dari string.

Dan baru kemarin saya berlari ke kode yang menempatkan dua item ke dalam array, mengubah array menjadi JSON, memasukkan JSON ke dalam string, memasukkan string ke dalam array, mengubah seluruh array menjadi JSON, mengirimkannya ke klien, yang diterjemahkan JSON, mendapat array berisi string, mengambil string, mengekstraksi JSON dari string, mendekodekan JSON, dan mendapat array dengan dua item. Jangan lakukan itu.


+1 Tepat. Pertanyaan pertama adalah, apa yang perlu Anda terima? Akan ada sedikit kesalahan dengan endpoint yang mengembalikan iklan sidebar sebagai sedikit HTML, atau mungkin footer, atau elemen serupa.
SQB

3

Ini semua tergantung pada tujuan API, tetapi umumnya apa yang Anda gambarkan adalah pelanggaran yang cukup kuat atas pemisahan masalah :

Dalam aplikasi modern, kode API harus bertanggung jawab atas data, dan kode klien harus bertanggung jawab untuk presentasi.

Ketika API Anda mengembalikan HTML, Anda dengan erat menyatukan data dan presentasi Anda. Ketika API mengembalikan HTML, satu-satunya hal yang dapat Anda lakukan (dengan mudah) dengan HTML adalah menampilkannya sebagai bagian dari halaman yang lebih besar. Dari sudut pandang yang berbeda, satu-satunya hal yang baik untuk API adalah menyediakan halaman Anda dengan HTML. Plus, Anda telah menyebarkan HTML Anda ke kode klien dan server. Ini bisa membuat perawatan sakit kepala.

Jika API Anda mengembalikan JSON, atau bentuk data murni lainnya, itu menjadi jauh lebih berguna. Aplikasi yang ada masih dapat mengkonsumsi data itu, dan menyajikannya dengan tepat. Namun, sekarang hal-hal lain dapat menggunakan API untuk mengakses data yang sama. Sekali lagi, pemeliharaannya lebih mudah - semua HTML ada di satu tempat, jadi jika Anda ingin mengubah gaya seluruh situs, Anda tidak perlu mengubah API Anda.


5
"Dalam aplikasi modern, kode API harus bertanggung jawab atas data, dan kode klien harus bertanggung jawab atas presentasi." Kenapa harus selalu demikian? Saya setuju bahwa ini adalah pola umum dan membuat hal-hal tertentu lebih mudah, tetapi saya tidak melihat alasan untuk menaikkannya ke tingkat "harus" ... Ini adalah keputusan yang perlu diambil berdasarkan kasus per kasus, dan tentu saja ada alasan mengapa dalam beberapa situasi Anda mungkin ingin membuat keputusan yang berbeda.
Jules

@ Jules karena jika Anda memiliki API dan klien, memiliki keduanya yang bertanggung jawab atas rendering merupakan pelanggaran pemisahan masalah. (Sekarang, Anda tidak perlu memiliki API dan klien. Anda hanya dapat memiliki satu komponen, dan membuatnya melakukan seluruh presentasi. Tetapi kemudian Anda tidak memiliki API)
njzk2

@ njzk2 Hanya karena API memberikan data HTML tidak berarti telah membuatnya. Ini mungkin memperlakukan HTML sebagai gumpalan dan menyimpannya dalam database, misalnya. Juga, beberapa rendering mungkin diperlukan di server daripada klien (misalnya menyediakan halaman statis untuk mesin pencari) sehingga menggunakan kembali kemampuan yang dapat dilihat sebagai penghapusan duplikasi.
Jules

1
Juga, sangat mungkin untuk menghasilkan sepasang klien dan api di mana semua rendering terjadi di server dan klien hanya memasukkan HTML yang dikirim ke slot yang telah ditentukan di DOM itu. Jquery memiliki seluruh modul yang didedikasikan untuk klien jenis ini, yang menunjukkan kepada saya bahwa mereka harus cukup umum.
Jules

1
@ Jules banyak hal yang cukup umum, itu bukan alasan mengapa mereka masuk akal.
njzk2

2

HTML terikat dengan desain dan penggunaan tertentu.

Dengan HTML, jika Anda ingin mengubah tata letak halaman, Anda perlu mengubah cara html dihasilkan oleh panggilan server. Biasanya, itu membutuhkan programmer back-end. Sekarang Anda memiliki pemrogram back-end, yang menurut definisi bukan penulis html terbaik Anda, menangani pembaruan ini.

Dengan JSON, jika tata letak halaman berubah, panggilan server JSON yang ada tidak harus berubah sama sekali. Sebaliknya, pengembang front-end Anda, atau bahkan perancang, memperbarui templat untuk menghasilkan HTML berbeda yang Anda inginkan dari data dasar yang sama.

Selain itu, JSON dapat menjadi dasar untuk layanan lain. Anda mungkin memiliki peran berbeda yang perlu melihat data dasar yang sama dengan cara yang berbeda. Misalnya, Anda mungkin memiliki situs web pelanggan yang menunjukkan data tentang suatu produk di halaman pemesanan, dan halaman penjualan di dalam untuk repetisi yang menunjukkan data yang sama dalam tata letak yang sangat berbeda, mungkin di samping beberapa informasi lain yang tidak tersedia untuk pelanggan umum. Dengan JSON, panggilan server yang sama dapat digunakan di kedua tampilan.

Akhirnya, JSON dapat skala yang lebih baik. Dalam beberapa tahun terakhir kami sudah agak berlebihan dengan kerangka kerja javascript sisi klien. Saya pikir inilah saatnya untuk benar-benar mundur dan mulai berpikir tentang javascript apa yang kami gunakan, dan bagaimana hal itu memengaruhi kinerja peramban ... terutama pada perangkat seluler. Yang mengatakan, jika Anda menjalankan situs yang cukup besar untuk memerlukan server farm atau cluster, alih-alih satu server, JSON dapat skala yang lebih baik. Pengguna akan memberi Anda waktu pemrosesan di browser mereka secara gratis, dan jika Anda memanfaatkannya, Anda dapat mengurangi beban server dalam penyebaran besar. JSON juga menggunakan lebih sedikit bandwidth, jadi sekali lagi, jika Anda cukup besardan menggunakannya dengan tepat, JSON secara terukur lebih murah. Tentu saja, ini juga dapat skala lebih buruk, jika Anda akhirnya memberi makan 40KB perpustakaan untuk mengurai 2KB data menjadi 7KB dari html, jadi sekali lagi: membayar untuk menyadari apa yang Anda lakukan. Tetapi ada potensi untuk JSON untuk meningkatkan kinerja dan biaya.


1

Tidak ada yang salah dengan titik akhir jika memenuhi persyaratannya. Jika diharuskan untuk meludah html bahwa konsumen yang dikenal dapat mengurai secara efektif, tentu, mengapa tidak

Masalahnya adalah, untuk kasus umum, Anda ingin titik akhir Anda memuntahkan muatan yang terbentuk dengan baik dan secara efektif dapat diurai oleh parser standar. Dan dengan mampu mengurai secara efektif, maksud saya, mampu mengurai secara deklaratif.

Jika klien Anda dipaksa untuk membaca payload dan membuka bit informasi dari itu dengan loop dan jika-pernyataan, maka itu tidak dapat diurai secara efektif. Dan HTML, sebagai caranya, itu sangat dimaafkan karena tidak membutuhkan dirinya untuk dibentuk dengan baik.

Sekarang, jika Anda memastikan html Anda kompatibel dengan xml, maka Anda adalah emas.

Dengan itu, saya punya masalah signifikan dengan ini:

Saya akan memberitahu Anda ini: titik akhir yang mengembalikan HTML mengurangi ketergantungan Anda pada pustaka JavaScript dan mengurangi beban pada browser pengguna karena tidak perlu menafsirkan / mengeksekusi kode JS untuk membuat objek DOM - HTML sudah ada di sana, itu hanya masalah penguraian elemen dan rendering mereka. Tentu saja, ini berarti kita berbicara tentang jumlah data yang masuk akal. 10 megabita data HTML tidak masuk akal.

Itu ide yang buruk tidak peduli bagaimana Anda memotongnya. Beberapa dekade pengalaman industri kolektif telah menunjukkan kepada kita bahwa, secara umum, adalah ide yang baik untuk memisahkan data (atau model) dari tampilannya (atau tampilan).

Di sini Anda menggabungkan keduanya untuk tujuan eksekusi kode JS cepat. Dan itu optimasi mikro.

Saya belum pernah melihat ini sebagai ide yang baik kecuali dalam sistem yang sangat sepele.

Saran saya? Jangan lakukan itu. HC SVNT DRACONES , YMMV, dll.


0

JSON hanyalah presentasi tekstual dari data terstruktur. Seorang klien secara alami perlu memiliki parser untuk memproses data tetapi hampir semua bahasa memiliki fungsi parser JSON. Adalah jauh lebih efisien untuk menggunakan JSON parser daripada menggunakan parser HTML. Dibutuhkan sedikit jejak. Tidak demikian halnya dengan parser HTML.

Di PHP, Anda cukup menggunakan json_encode($data)dan terserah klien di sisi lain untuk menguraikannya. Dan ketika Anda mengambil data JSON dari layanan web, Anda hanya menggunakan $data=json_decode($response)dan Anda dapat memutuskan bagaimana menggunakan data seperti yang akan Anda lakukan dengan variabel.

Misalkan Anda mengembangkan aplikasi untuk perangkat seluler, mengapa Anda memerlukan format HTML ketika aplikasi seluler jarang menggunakan peramban web untuk memilah data? Banyak aplikasi seluler menggunakan JSON (format paling umum) untuk bertukar data.

Mengingat bahwa ponsel sering menggunakan paket terukur, mengapa Anda ingin menggunakan HTML yang membutuhkan bandwidth lebih banyak daripada JSON?

Mengapa menggunakan HMTL ketika HTML terbatas dalam kosa katanya dan JSON dapat mendefinisikan data? {"person_name":"Jeff Doe"}lebih informatif daripada HTML dapat menyediakan tentang datanya karena hanya mendefinisikan struktur untuk parser HTML, bukan mendefinisikan data.

JSON tidak ada hubungannya dengan HTTP. Anda bisa memasukkan JSON ke dalam file. Anda dapat menggunakannya untuk konfigurasi. Komposer menggunakan JSON. Anda dapat menggunakannya untuk menyimpan variabel sederhana ke file juga.


0

Sulit untuk mengkategorikan benar atau salah. IMO, pertanyaan saya akan tanyakan adalah: " haruskah itu ", atau " dapatkah itu dilakukan dengan kurang? ".

Setiap titik akhir harus berusaha keras untuk berkomunikasi dengan konten sesedikit mungkin. Rasio signal-to-noise biasanya kode HTTP <JSON <XHTML. Dalam sebagian besar situasi, ada baiknya memilih protokol yang paling tidak berisik.

Saya berbeda pada poin tentang memuat browser klien oleh @machado, karena dengan browser modern ini bukan masalah. Sebagian besar dari mereka dilengkapi dalam menangani kode HTTP dan respons JSON dengan cukup baik. Dan meskipun Anda tidak memiliki tes saat ini, pemeliharaan jangka panjang dari protokol yang kurang berisik akan lebih murah daripada yang di atasnya.

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.