"REST Vs GraphQL" apakah ini perbandingan yang benar?


8

Saya melihat di banyak situs yang membandingkan REST dengan GraphQL. setelah menyelidiki kekhawatiran ini (sebenarnya kekhawatiran saya) bahwa, "apakah ini perbandingan yang benar?", saya menjadi lebih bingung. Karena REST memiliki definisi yang berbeda terhadap GraphQL, pertanyaan ini menyibukkan pikiran saya, mengapa kita dapat membandingkan dua konsep yang berbeda secara bersamaan.

sebenarnya, menurut saya perbandingannya adalah seperti ini:

IDE Vs Compiler! ??! atau BMW x6 Vs ISO 18541-5 (Kendaraan jalan)

dari wiki:

Definisi istirahat:

Representational State Transfer (REST) adalah gaya arsitektur perangkat lunak yang menetapkan serangkaian kendala yang akan digunakan untuk membuat layanan Web.

Definisi GraphQl:

GraphQL adalah kueri sumber data terbuka dan bahasa manipulasi untuk API, dan runtime untuk memenuhi kueri dengan data yang ada.

tolong cerahkan pikiran saya dengan jawaban Anda. Terima kasih


Halaman utama GraphQL sudah menggambarkan perbedaan dengan cukup baik. Apa yang secara spesifik Anda butuhkan tentang kecerahan tambahan?
Robert Harvey

1
Kedua hal tidak dapat dibandingkan kecuali Anda memilih untuk menyederhanakan apa REST itu dan menguranginya menjadi CRUDS web semata-mata melalui HTTP, apa yang pasti tidak. Ini seperti membandingkan SOA dengan SQL.
Laiv

Bisakah Anda menambahkan beberapa contoh artikel / situs tersebut? Ini akan membantu kita untuk mengetahui sumber-sumber untuk pertanyaan ini :)
CorwinCZ

Jawaban:


7

REST adalah gaya arsitektur, yang dikembangkan secara paralel dengan web di seluruh dunia pada 1990-an.

World Wide Web adalah aplikasi referensi untuk gaya arsitektur REST (dengan beberapa penyimpangan ).

HTTP adalah protokol aplikasi untuk mentransfer dokumen melalui jaringan.

GraphQL adalah bahasa permintaan dan mesin eksekusi .

Anda benar bahwa secara langsung membandingkan REST dan GraphQL berantakan. Namun, yang dapat Anda lakukan adalah melihat dengan cermat jenis-jenis masalah yang mereka coba selesaikan.

Dengan menerapkan prinsip rekayasa perangkat lunak generalitas ke antarmuka komponen, arsitektur sistem keseluruhan disederhanakan dan visibilitas interaksi ditingkatkan. Implementasi dipisahkan dari layanan yang mereka berikan, yang mendorong evolvabilitas independen. Namun, trade-off adalah antarmuka yang seragam menurunkan efisiensi, karena informasi ditransfer dalam bentuk standar daripada yang khusus untuk kebutuhan aplikasi. Antarmuka REST dirancang agar efisien untuk transfer data hypermedia berbutir besar, mengoptimalkan untuk kasus umum Web, tetapi menghasilkan antarmuka yang tidak optimal untuk bentuk lain dari interaksi arsitektur. Fielding, 2000

Dalam REST, caching adalah masalah besar, dan spesifikasi HTTP saat ini memiliki seluruh RFC yang didedikasikan untuk caching semantik; tetapi orang-orang yang menggunakan GraphQL rupanya memutuskan bahwa caching tidak signifikan untuk masalah mereka.

Seperti yang bisa saya katakan, GraphQL membuat banyak pilihan kopling yang sama dengan SOAP . Itu tidak benar atau salah - hanya penyeimbang trade off yang berbeda.


5

Tidak, perbandingan ini tidak valid.

Seperti yang Anda katakan, GraphQL dan REST adalah hal yang berbeda, jadi itu seperti membandingkan apel dan jeruk.

Itulah salah satu pandangan / perspektif masalah ini. Yang kedua adalah sebaliknya - perbandingan GraphQL / REST valid dan sangat berguna .

Untuk memahami pandangan kedua ini, kita harus mengajukan pertanyaan ini:

Apa cara yang mungkin untuk mengirimkan data saya ke klien? Yang mana yang harus saya pilih?

Jawaban untuk pertanyaan pertama berisi REST dan GraphQL (dengan banyak cara lain). Keduanya berguna untuk mengirimkan data ke klien (baca - membuat API). Pertanyaan kedua sebenarnya adalah pertanyaan yang berdiri di belakang semua perbandingan yang telah Anda baca.

Membandingkan berbagai cara bagaimana mengirimkan data adalah sah dan perlu. Dari sudut pandang ini, tidak masalah bahwa sifat dari hal-hal yang dibandingkan berbeda. Keduanya dapat melakukan pekerjaan itu, jadi Anda harus membandingkannya.

Ini seperti membandingkan rasa apel dan jeruk - Anda dapat melakukannya.

Secara pribadi saya melakukan perbandingan ini sepanjang waktu. Sangat berguna untuk mengajari sesama rekan kerja berbagai cara bagaimana menyelesaikan masalah.

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.