So sánh tốc độ post và get

Giao Thức Truyền Tải Siêu Văn Bản [HTTP] được thiết kế cho phép thực hiện các giao tiếp giữa máy khách và máy chủ.

HTTP làm việc dựa trên giao thức yêu cầu – phản hồi giữa máy khách và server.

Một trình duyệt web có thể là máy khách và một ứng dụng trên máy tính được lưu trữ như một website có thể là server.

Ví dụ: Một máy khách [trình duyệt] gửi yêu cầu HTTP tới server; sau đó server hồi đáp lại yêu cầu của máy khách. Việc hồi đáp này bao gồm thông tin trạng thái về yêu cầu và có thể còn bao gồm cả nội dung đã yêu cầu.

Có hai phương thức thường được sử dụng để yêu cầu và hồi đáp giữa máy khách và server là: GET và POST.

  • GET – Các yêu cầu dữ liệu từ một nguồn chỉ định
  • POST – Gửi dữ liệu để xử lý tới một nguồn nhất định

Phương thức GET

Lưu ý chuỗi truy vấn [cặp tên / giá trị] được gửi đi trong URL của phương thức truy vấn GET:

/ducanhfile/demo.php?name1=value1&name2=value2

Một số lưu khác về truy vấn GET:

  • Truy vấn GET có thể được lưu lại [cached]
  • Truy vấn GET vẫn được lưu lại trong lịch sử trình duyệt
  • Truy vấn GET có thể được bookmark [đánh dấu rồi xem lại sau]
  • Truy vấn GET không bao giờ được sử dụng để gửi đi các dữ liệu nhạy cảm
  • Truy vấn GET có những hạn chế về chiều dài dữ liệu
  • Truy vấn GET chỉ nên sử dụng cho việc lấy dữ liệu GET

Phương thức POST

Lưu ý rằng chuỗi truy vấn [cặp tên/giá trị] được gửi đi trong thông điệp HTTP của truy vấn request:

POST /test/demo_form.php HTTP/1.1
Host: freehost.page
name1=value1&name2=value2

Một số lưu ý khác về truy vấn POST:

  • Truy vấn POST không bao giờ được lưu trữ [cached]
  • Truy vấn POST không được lưu lại trong lịch sử tình duyệt
  • Truy vấn POST không thể bookmark
  • Truy vấn POST không hạn chế chiều dài dữ liệu

So sánh GET và POST

Bảng dưới đây so sánh hai phương thức GET và POST.

GET POST Khi tải lại trang hoặc nhấn nút BACK trên trình duyệt Vô hại Dữ liệu sẽ được gửi thêm lần nữa [trình duyệt phải cảnh báo người dùng rằng dữ liệu sẽ được gửi lên lần nữa] Bookmark Có thể bookmark Không thể bookmark Bộ nhớ Cached Có thể được lưu trong bộ nhớ cached Không lưu trong bộ nhớ cached Kiểu Encoding application/x-www-form-urlencoded application/x-www-form-urlencoded hoặc multipart/form-data. Sử dụng mã hóa nhiều phần cho dữ liệu nhị phân Lịch sử Các thông số vẫn được lưu trữ trong lịch sử trình duyệt Các thông số không được lưu trữ trong lịch sử trình duyệt Các hạn chế về chiều dài dữ liệu Vâng, khi gửi dữ liệu, phương thức GET thêm dữ liệu vào URL; và độ dài tối đa của URL là có giới hạn [con số cụ thể là 2048 ký tự] Không có hạn chế Hạn chế trong kiểu dữ liệu Chỉ bảng mã ASCII được chấp nhận [vì nó liên quan đến URL] Không có hạn chế. Dữ liệu nhị phân cũng được phép Bảo mật GET kém an toàn hơn khi so với POST, bởi vì dữ liệu gửi đi có một phần trong URL

Không bao giờ được dùng GET khi gửi dữ liệu mật khẩu [password] hoặc các thông tin nhạy cảm [ví dụ số thẻ ngân hàng]

POST an toàn hơn một chút so với GET bởi vì thông số không được lưu trữ trong lịch sử duyệt web hoặc trong web server logs Lộ Dữ liệu được hiển thị cho tất cả mọi người trong URL Dữ liệu không được hiển thị trong URL

Các phương thức truy vấn HTTP khác

Bảng dưới đây liệt kê một số phương thức truy vấn HTTP khác:

Phương thức Mô tả HEAD Tương tự như GET nhưng chỉ trả về HTTP header và không có thân tài liệu PUT Tải lên một đại diện xác định của URI DELETE Xoá tài nguyên xác định OPTIONS Quay trở lại phương thức HTTP mà server hỗ trợ CONNECT Chuyển đổi các yêu cầu kết nối đến một tunnel TCP/IP

Sinh năm 1987, tốt nghiệp Cao đẳng thực hành FPT quãng 2014, chuyên ngành Thiết kế website. Tôi thích Content, SEO, Ads, Tăng tốc website và Thương mại điện tử. Bên cạnh bài tự viết, tôi cũng dịch nhiều nội dung thú vị của các tác giả khác nhau. FB cá nhân: facebook.com/anhducnguyen87. Email liên hệ: guiemailchotoi@gmail.com

SOAP là một giao thức trong khi REST là một kiểu kiến trúc. Điều này tạo ra nhiều điểm khác biệt đáng kể trong cách SOAP API và API REST hoạt động.

Thiết kế

SOAP API cho phép truy cập các hàm hoặc các thao tác, trong khi API REST dựa trên dữ liệu. Ví dụ: hãy xem xét một ứng dụng có dữ liệu nhân viên mà các ứng dụng khác có thể thao tác. SOAP API của ứng dụng có thể cho phép truy cập một hàm được gọi là CreateEmployee. Để tạo một nhân viên, bạn sẽ chỉ rõ ra tên của hàm trong tin nhắn SOAP của bạn khi gửi yêu cầu.

Tuy nhiên, API REST của ứng dụng có thể cho phép truy cập một URL được gọi là /employees, và một yêu cầu POST đến URL đó sẽ tạo ra một hồ sơ nhân viên mới.

Sự linh hoạt

SOAP API thì cứng nhắc và chỉ cho phép trao đổi tin nhắn XML giữa các ứng dụng. Máy chủ ứng dụng cũng phải duy trì trạng thái của mỗi máy khách. Điều này có nghĩa là máy chủ phải ghi nhớ tất cả các yêu cầu trước đó khi xử lý một yêu cầu mới.

REST linh hoạt hơn và cho phép các ứng dụng truyền dữ liệu dưới dạng văn bản thuần túy, HTML, XML và JSON. REST cũng không có trạng thái nên API REST xử lý mọi yêu cầu mới một cách độc lập với các yêu cầu trước đó.

Hiệu năng

Tin nhắn SOAP lớn hơn và phức tạp hơn, khiến quá trình truyền tải và xử lý những tin nhắn này chậm hơn. Điều này có thể làm tăng thời gian tải trang.

REST nhanh hơn và hiệu quả hơn SOAP do kích thước tin nhắn của REST nhỏ hơn. Các phản hồi của REST cũng có thể được lưu trữ trong bộ nhớ đệm, do đó, máy chủ có thể lưu trữ những dữ liệu được truy cập thường xuyên trong bộ nhớ đệm để giảm hơn nữa thời gian tải trang.

Khả năng điều chỉnh quy mô

Giao thức SOAP yêu cầu các ứng dụng lưu trữ trạng thái giữa các yêu cầu, làm tăng yêu cầu về băng thông và bộ nhớ. Do đó, SOAP khiến các ứng dụng tốn kém và khó khăn trong việc điều chỉnh quy mô.

Không giống như SOAP, REST cho phép sử dụng kiến trúc không trạng thái và phân lớp, khiến REST dễ dàng điều chỉnh quy mô hơn. Ví dụ: máy chủ ứng dụng có thể truyền yêu cầu đến các máy chủ khác hoặc cho phép một phương tiện trung gian [ví dụ như một mạng phân phối nội dung] xử lý yêu cầu.

Bảo mật

SOAP cần thêm một lớp Bảo mật WS để làm việc với HTTPS. Bảo mật WS sử dụng thêm nội dung phần tiêu đề để đảm bảo chỉ có quy trình được chỉ định trong máy chủ cụ thể mới có thể đọc nội dung tin nhắn của SOAP. Điều này tăng thêm lượng giao tiếp quá mức và ảnh hưởng tiêu cực đến hiệu năng.

REST hỗ trợ HTTPS mà không cần thêm tài nguyên máy quá mức.

Độ tin cậy

SOAP tích hợp sẵn logic xử lý lỗi và có độ tin cậy cao hơn. Mặt khác, REST yêu cầu bạn thử lại trong trường hợp giao tiếp thất bại và ít đáng tin cậy hơn.

Chủ Đề