Khi nào tôi nên sử dụng phương thức GET hoặc POST? Sự khác biệt giữa chúng là gì?


249

Sự khác biệt khi sử dụng GEThoặc POSTphương pháp là gì? Cái nào an toàn hơn? (Dis) lợi thế của mỗi người trong số họ là gì?

( câu hỏi tương tự )


2
Get không có phần thân nên trong thực tế có nghĩa là bạn bị giới hạn ở tên -> cặp giá trị dưới dạng cấu trúc dữ liệu do thiếu bất kỳ định dạng mã hóa chuỗi truy vấn nào cho cấu trúc phức tạp hơn. Nếu bạn cần xử lý các cấu trúc dữ liệu phức tạp hơn trong các yêu cầu của mình (ví dụ như một mảng, đối tượng, v.v.), bạn cần sử dụng POST và có lẽ các định dạng nâng cao hơn (json / xml). Nói ngắn gọn: không sử dụng GET trừ khi bạn thực sự phải (ví dụ: URL / tài nguyên phải được khám phá).
themihai

Câu trả lời:


263

Đó không phải là vấn đề an ninh. Giao thức HTTP định nghĩa các yêu cầu kiểu GET là idempotent , trong khi POST có thể có tác dụng phụ. Trong tiếng Anh đơn giản, điều đó có nghĩa là GET được sử dụng để xem một cái gì đó, mà không thay đổi nó, trong khi POST được sử dụng để thay đổi một cái gì đó. Ví dụ: một trang tìm kiếm nên sử dụng GET, trong khi một hình thức thay đổi mật khẩu của bạn nên sử dụng POST.

Ngoài ra, lưu ý rằng PHP nhầm lẫn các khái niệm một chút. Một yêu cầu POST được nhập từ chuỗi truy vấn và thông qua thân yêu cầu. Một yêu cầu GET chỉ nhận đầu vào từ chuỗi truy vấn. Vì vậy, một yêu cầu POST là một siêu bộ của một yêu cầu GET; bạn có thể sử dụng $_GETtrong một yêu cầu POST và thậm chí có thể có ý nghĩa khi có các tham số có cùng tên $_POST$_GETđiều đó có nghĩa là những thứ khác nhau.

Ví dụ: giả sử bạn có một biểu mẫu để chỉnh sửa một bài viết. Id bài viết có thể nằm trong chuỗi truy vấn (và, do đó, có sẵn thông qua $_GET['id']), nhưng hãy nói rằng bạn muốn thay đổi id bài viết. Id mới sau đó có thể có mặt trong thân yêu cầu ( $_POST['id']). OK, có lẽ đó không phải là ví dụ tốt nhất, nhưng tôi hy vọng nó minh họa sự khác biệt giữa hai điều này.


13
Chắc chắn có một khía cạnh bảo mật cho sự khác biệt giữa GET và POST. Chẳng hạn, một trang web độc hại có thể dính một yêu cầu GET tùy ý trong thẻ hình ảnh, khiến người dùng thực hiện GET đối với máy chủ khác. Nếu GET này giống như máy chủ khác / deletemyaccount thì điều tồi tệ sẽ xảy ra.
Frank Schwieterman

2
Ý tôi là nội dung của $ _POST không bị ẩn một cách kỳ diệu khỏi những người dùng độc hại. Rõ ràng có các khía cạnh bảo mật cho tất cả các chương trình điều.
troelskn

1
Bài đăng này không trả lời hoàn toàn câu hỏi vì anh ta không đề cập đến ý nghĩa bảo mật. Phần trên cùng là tốt miễn là lỗi chính tả "đau tiếng Anh" được đổi thành "tiếng Anh đơn giản". Phần dưới cùng là quá khó để làm theo. Nhìn chung, tốt hơn nhiều so với bài viết của tôi tho. :-)
Akrikos

1
"Một yêu cầu POST được nhập từ chuỗi truy vấn và thông qua thân yêu cầu." IMHO điều này là không chính xác. Để sử dụng một trong hai đầu vào, bạn cần sử dụng $ _REQUEST. $ _POST không nhận được các mục url.
Gunnar Bernstein

1
@Frank Schwieterman Tôi biết bài đăng này đã cũ, nhưng xóa tài khoản của tôi không phải là idempotent và không nên sử dụng get.
frostymarvelous

77

Khi người dùng nhập thông tin dưới dạng và nhấp vào Gửi, có hai cách thông tin có thể được gửi từ trình duyệt đến máy chủ: trong URL hoặc trong phần thân của yêu cầu HTTP.

Phương thức GET, được sử dụng trong ví dụ trước đó, nối các cặp tên / giá trị vào URL. Thật không may, độ dài của URL bị giới hạn, vì vậy phương pháp này chỉ hoạt động nếu chỉ có một vài tham số. URL có thể bị cắt bớt nếu biểu mẫu sử dụng một số lượng lớn các tham số hoặc nếu các tham số chứa một lượng lớn dữ liệu. Ngoài ra, các tham số được truyền trên URL được hiển thị trong trường địa chỉ của trình duyệt không phải là nơi tốt nhất để mật khẩu được hiển thị.

Thay thế cho phương thức GET là phương thức POST. Phương thức này gói các cặp tên / giá trị bên trong phần thân của yêu cầu HTTP, tạo ra một URL sạch hơn và không đặt ra giới hạn kích thước nào cho đầu ra của biểu mẫu. Nó cũng an toàn hơn.


1
Làm thế nào là nó "an toàn" hơn?
Julian Reschke

4
bởi vì nó khó thay đổi hơn? bạn có thể thay đổi GET trong thanh địa chỉ, nhưng không dễ dàng gì với POST.
IAd CHƯƠNG

8
Máy chủ không thể tin tưởng khách hàng. Thiết kế ứng dụng của bạn xung quanh các giả định sai, không an toàn.
troelskn

openid cũng không lưu, vì nó có thể bị phá vỡ?
IAd CHƯƠNG

1
Tôi tin rằng đây là lời giải thích rõ ràng nhất - sự khác biệt về vị trí của dữ liệu được gửi. Cảm ơn bạn.
greenoldman

37

Câu trả lời tốt nhất là câu đầu tiên.

Bạn đang sử dụng:

  • NHẬN khi bạn muốn lấy dữ liệu (NHẬN DỮ LIỆU).
  • POST khi bạn muốn gửi dữ liệu (POST DATA).

2
Mẫu dịch vụ yêu cầu / phản hồi được sử dụng là gì và bạn muốn làm cả hai? ;) Tôi muốn sử dụng POST trong hầu hết các trường hợp khi tôi cần phản hồi lại.
Dmitry Pavlov

8
Nói chung là đúng. GEThoàn toàn có khả năng 'gửi' dữ liệu, vì vậy không phải là một câu trả lời rất chính xác.
Patrick Hofman

23

Có hai hàm ý "bảo mật" phổ biến khi sử dụng GET. Vì dữ liệu xuất hiện trong chuỗi URL, nên ai đó có thể nhìn qua vai bạn tại Thanh địa chỉ / URL có thể xem thứ gì đó mà họ không nên biết như cookie phiên có khả năng được sử dụng để chiếm quyền điều khiển phiên của bạn. Hãy nhớ rằng tất cả mọi người có điện thoại camera.

Hàm ý bảo mật khác GETphải thực hiện với GETcác biến được ghi vào nhật ký truy cập của hầu hết các máy chủ web như một phần của URL yêu cầu. Tùy thuộc vào tình hình, khí hậu quy định và độ nhạy cảm chung của dữ liệu, điều này có thể có khả năng gây lo ngại.

Một số khách hàng / tường lửa / hệ thống IDS có thể nhăn mặt khi GETyêu cầu chứa quá nhiều dữ liệu và do đó có thể cung cấp kết quả không đáng tin cậy.

POST hỗ trợ chức năng nâng cao như hỗ trợ cho đầu vào nhị phân nhiều phần được sử dụng để tải tệp lên máy chủ web.

POSTyêu cầu tiêu đề có độ dài nội dung có thể làm tăng độ phức tạp của việc triển khai ứng dụng khách cụ thể của ứng dụng vì kích thước của dữ liệu được gửi phải được biết trước để ngăn yêu cầu của khách hàng được hình thành trong chế độ gia tăng một lần duy nhất. Có lẽ một vấn đề nhỏ đối với những người chọn lạm dụng HTTPbằng cách sử dụng nó như một vận chuyển RPC (Cuộc gọi thủ tục từ xa).

Những người khác đã thực hiện một công việc tốt trong việc bao gồm các khác biệt về ngữ nghĩa và phần "khi nào" của câu hỏi này.


17

Tôi sử dụng GET khi tôi truy xuất thông tin từ URL và POST khi tôi gửi thông tin tới URL.


1
nhưng bạn có thể sử dụng GET để gửi là tốt. Sự khác biệt là định dạng (trong url (GET) hoặc trong yêu cầu (POST)).
eric

Nếu điểm cuối chấp nhận một tệp và trả về một dòng từ tệp (không liên quan đến việc tạo hoặc thay đổi dữ liệu hoặc cơ sở dữ liệu), thì điểm cuối nên là GET hoặc POST?
biến

17

Bạn nên sử dụng POST nếu có nhiều dữ liệu hoặc sắp xếp thông tin nhạy cảm (những thứ thực sự nhạy cảm cũng cần kết nối an toàn).

Sử dụng GET nếu bạn muốn mọi người có thể đánh dấu trang của bạn, bởi vì tất cả dữ liệu được bao gồm trong dấu trang.

Chỉ cần cẩn thận với những người nhấn REFRESH bằng phương thức GET, vì dữ liệu sẽ được gửi lại mỗi lần mà không cảnh báo người dùng (POST đôi khi cảnh báo người dùng về việc gửi lại dữ liệu).


Nếu điểm cuối chấp nhận một tệp và trả về một dòng từ tệp (không liên quan đến việc tạo hoặc thay đổi dữ liệu hoặc cơ sở dữ liệu), thì điểm cuối nên là GET hoặc POST?
biến

@variable POST. Trong trường hợp này, chủ yếu là vì POST được xây dựng để xử lý tải lên tệp và GET không chuẩn. Bạn sẽ phải gửi tệp mỗi lần tải trang, do đó, chỉ nên sử dụng POST tiêu chuẩn thay vì tệp GET + sẽ phá vỡ kỳ vọng của GET rằng URL sẽ mang lại kết quả tương tự ít hơn mỗi lần.
Cấp

14

Tài liệu W3C này giải thích việc sử dụng HTTP GET và POST.

Tôi nghĩ rằng nó là một nguồn có thẩm quyền.

Tóm tắt là (phần 1.3 của tài liệu):

  • Sử dụng GET nếu tương tác giống như một câu hỏi (nghĩa là đó là một hoạt động an toàn như truy vấn, thao tác đọc hoặc tra cứu).
  • Sử dụng POST nếu:
    • Sự tương tác giống như một đơn đặt hàng, hoặc
    • Sự tương tác thay đổi trạng thái của tài nguyên theo cách mà người dùng sẽ cảm nhận (ví dụ: đăng ký dịch vụ) hoặc
    • Người dùng phải chịu trách nhiệm về kết quả của sự tương tác.

9
Tôi nghĩ rằng có thể tóm tắt thêm như sau: NHẬN khi trạng thái của máy chủ không thay đổi, POST khi có.
Yamcha

10

Các phương thức Get và Post không liên quan gì đến công nghệ máy chủ mà bạn đang sử dụng, nó hoạt động tương tự trong php, asp.net hoặc ruby. GET và POST là một phần của giao thức HTTP. Như đã lưu ý, POST an toàn hơn. Các hình thức POST cũng không được trình duyệt lưu vào bộ nhớ cache. POST cũng được sử dụng để chuyển số lượng lớn dữ liệu.


8

Lý do sử dụng POST khi thực hiện thay đổi dữ liệu:

  • Trình tăng tốc web như Trình tăng tốc web của Google sẽ nhấp vào tất cả các liên kết (GET) trên một trang và lưu trữ chúng. Điều này là rất xấu nếu các liên kết thực hiện thay đổi cho mọi thứ.
  • Trình duyệt lưu các yêu cầu GET vì vậy ngay cả khi người dùng nhấp vào liên kết, nó có thể không gửi yêu cầu đến máy chủ để thực hiện thay đổi.
  • Để bảo vệ trang web / ứng dụng của bạn chống lại CSRF, bạn phải sử dụng POST. Để hoàn toàn bảo mật ứng dụng của bạn, sau đó bạn cũng phải tạo một mã định danh duy nhất trên máy chủ và gửi nó cùng với yêu cầu.

Ngoài ra, không đặt thông tin nhạy cảm trong chuỗi truy vấn (chỉ có tùy chọn với GET) vì nó hiển thị trên thanh địa chỉ, dấu trang và nhật ký máy chủ.

Hy vọng điều này giải thích tại sao mọi người nói POST là 'an toàn'. Nếu bạn đang truyền dữ liệu nhạy cảm, bạn phải sử dụng SSL.


8

GETPOSTlà các phương thức HTTP có thể đạt được các mục tiêu tương tự

GETvề cơ bản là chỉ để lấy (lấy) dữ liệu, A GETkhông nên có phần thân, vì vậy ngoài cookie, nơi duy nhất để truyền thông tin là trong URL và URL bị giới hạn về độ dài, GETkém an toàn hơn so với POSTvì dữ liệu được gửi là một phần của URL

Không bao giờ sử dụng GETkhi gửi mật khẩu, thẻ tín dụng hoặc thông tin nhạy cảm khác!, Dữ liệu được hiển thị cho mọi người trong URL, Có thể được lưu trữ dữ liệu. GETlà vô hại khi chúng tôi tải lại hoặc gọi lại nút, nó sẽ được đánh dấu sách, các tham số vẫn còn trong lịch sử trình duyệt, chỉ cho phép các ký tự ASCII.

POSTcó thể liên quan đến bất cứ điều gì, như lưu trữ hoặc cập nhật dữ liệu, hoặc đặt hàng sản phẩm hoặc gửi e-mail. POSTPhương pháp có một cơ thể.

POSTphương thức được bảo mật để truyền thông tin nhạy cảm và bí mật đến máy chủ, nó sẽ không hiển thị trong các tham số truy vấn trong URL và các tham số không được lưu trong lịch sử trình duyệt. Không có giới hạn về chiều dài dữ liệu. Khi chúng tôi tải lại trình duyệt sẽ thông báo cho người dùng rằng dữ liệu sắp được gửi lại. POSTphương pháp không thể được đánh dấu


3
  1. Phương thức GET được sử dụng để gửi dữ liệu ít nhạy cảm hơn trong khi phương thức POST được sử dụng để gửi dữ liệu nhạy cảm.
  2. Sử dụng phương thức POST, bạn có thể gửi lượng dữ liệu lớn so với phương thức GET.
  3. Dữ liệu được gửi bằng phương thức GET hiển thị trong thanh tiêu đề của trình duyệt trong khi dữ liệu được gửi bằng phương thức POST là vô hình.

0

Sử dụng phương thức GET nếu bạn muốn lấy tài nguyên từ URL. Bạn luôn có thể nhìn thấy trang cuối cùng nếu bạn nhấn nút quay lại của trình duyệt và nó có thể được đánh dấu, vì vậy nó không an toàn như phương thức POST.

Sử dụng phương thức POST nếu bạn muốn 'gửi' một cái gì đó đến URL. Ví dụ: bạn muốn tạo tài khoản google và bạn có thể cần điền tất cả thông tin chi tiết, sau đó bạn nhấn nút 'gửi' (phương thức POST được gọi ở đây), sau khi bạn gửi thành công và thử nhấn nút quay lại trình duyệt của bạn , bạn sẽ gặp lỗi hoặc một biểu mẫu trống mới, thay vì trang cuối cùng với biểu mẫu đã điền.


-10

Các GETphương pháp:

  • Nó chỉ được sử dụng để gửi ngày 256 ký tự

  • Khi sử dụng phương pháp này, thông tin có thể được nhìn thấy trên trình duyệt

  • Đây là phương thức mặc định được sử dụng bởi các biểu mẫu

  • Nó không được bảo mật như vậy.


Các POSTphương pháp:

  • Nó được sử dụng để gửi dữ liệu không giới hạn.

  • Với phương pháp này, thông tin không thể nhìn thấy trên trình duyệt

  • Bạn có thể đề cập rõ ràng đến POSTphương pháp

  • Nó được bảo mật hơn GETphương thức

  • Nó cung cấp các tính năng nâng cao hơn


"Nó chỉ được sử dụng để gửi ngày 256 ký tự" - không đúng. "Khi sử dụng phương pháp này, thông tin có thể được nhìn thấy trên trình duyệt" - dữ liệu bài đăng cũng được hiển thị trong trình duyệt, nó không quá rõ ràng. "Nó cung cấp các tính năng nâng cao hơn" - chẳng hạn như?
Quentin

Đây không phải là một câu trả lời cực kỳ hữu ích. Thông tin không chính xác như 'nó không được bảo mật' và 'cung cấp các tính năng nâng cao hơn' và những thứ khác được Quentin đề cập.
Andrew Barber
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.