REST REST Vs GraphQL Đây có phải là một so sánh chính xác?

Tôi thấy trong nhiều trang web so sánh REST với GraphQL. sau khi điều tra mối quan tâm này (thực sự là mối quan tâm của tôi) rằng, "đó có phải là một so sánh chính xác không?", tôi càng bối rối hơn. Vì REST có định nghĩa khác với GraphQL, nên câu hỏi này làm tôi bận tâm rằng, tại sao chúng ta có thể so sánh hai khái niệm khác nhau với nhau.

Thật ra, đối với tôi, sự so sánh là như thế này:

Trình biên dịch IDE Vs! ??! hoặc BMW x6 Vs ISO 18541-5 (Phương tiện giao thông đường bộ)

từ wiki:

Định nghĩa còn lại:

Chuyển giao trạng thái đại diện (REST) là một kiểu kiến ​​trúc phần mềm xác định một tập các ràng buộc sẽ được sử dụng để tạo các dịch vụ Web.

Định nghĩa của GraphQl:

GraphQL là ngôn ngữ thao tác và truy vấn dữ liệu nguồn mở cho API và thời gian chạy để thực hiện các truy vấn với dữ liệu hiện có.

xin vui lòng làm sáng tâm trí của tôi với câu trả lời của bạn. cảm ơn

REST là một phong cách kiến ​​trúc, được phát triển song song với thế giới web vào những năm 1990.

World Wide Web là một ứng dụng tham khảo cho phong cách kiến ​​trúc REST (với một số sai lệch ).

HTTP là một giao thức ứng dụng để chuyển tài liệu qua mạng.

GraphQL là ngôn ngữ truy vấn và công cụ thực thi .

Bạn đúng khi so sánh trực tiếp REST và GraphQL là một mớ hỗn độn. Tuy nhiên, những gì bạn có thể làm là xem xét cẩn thận các loại vấn đề mà họ đang cố gắng giải quyết.

Bằng cách áp dụng nguyên tắc công nghệ phần mềm về tính tổng quát cho giao diện thành phần, kiến ​​trúc hệ thống tổng thể được đơn giản hóa và khả năng hiển thị của các tương tác được cải thiện. Việc triển khai được tách rời khỏi các dịch vụ mà họ cung cấp, điều này khuyến khích khả năng phát triển độc lập. Mặc dù vậy, sự đánh đổi là một giao diện thống nhất làm giảm hiệu quả, vì thông tin được truyền dưới dạng chuẩn chứ không phải là giao diện cụ thể cho nhu cầu của ứng dụng. Giao diện REST được thiết kế để có hiệu quả cho việc truyền dữ liệu hypermedia hạt lớn, tối ưu hóa cho trường hợp phổ biến của Web, nhưng dẫn đến giao diện không tối ưu cho các hình thức tương tác kiến ​​trúc khác. Fielding, 2000

Trong REST, bộ nhớ đệm là một vấn đề lớn và đặc tả HTTP hiện tại có toàn bộ RFC dành riêng cho ngữ nghĩa bộ đệm; nhưng những người sử dụng GraphQL rõ ràng đã quyết định rằng bộ nhớ đệm không quan trọng đối với vấn đề của họ.

Như tôi có thể nói, GraphQL đang đưa ra rất nhiều lựa chọn ghép giống như SOAP . Điều đó không đúng hay sai - chỉ là sự cân bằng khác nhau của sự đánh đổi.

Không, so sánh này không hợp lệ.

Như bạn đã nói, GraphQL và REST là những thứ khác nhau, vì vậy nó giống như so sánh táo và cam.

Đó là một quan điểm / quan điểm của vấn đề này. Thứ hai hoàn toàn ngược lại - so sánh GraphQL / REST là hợp lệ và rất hữu ích .

Để hiểu quan điểm thứ hai này, chúng ta phải đặt câu hỏi này:

Các cách có thể để cung cấp dữ liệu của tôi cho khách hàng là gì? Tôi nên chọn cái nào?

Trả lời cho câu hỏi đầu tiên chứa cả REST và GraphQL (với nhiều cách khác). Cả hai đều hữu ích để phân phối dữ liệu cho khách hàng (đọc - tạo API). Câu hỏi thứ hai thực sự là câu hỏi đứng đằng sau tất cả các so sánh bạn đã đọc.

So sánh các cách khác nhau để cung cấp dữ liệu là hợp lệ và cần thiết. Từ quan điểm này, không có vấn đề gì về bản chất của những thứ được so sánh là khác nhau. Cả hai đều có thể thực hiện công việc, vì vậy bạn nên so sánh chúng.

Nó giống như so sánh hương vị của táo và cam - bạn có thể làm điều đó.

Cá nhân tôi đang làm so sánh này tất cả các thời gian. Rất hữu ích cho việc dạy các đồng nghiệp cách khác nhau để giải quyết vấn đề.