Ok, tôi biết sự khác biệt về mục đích. GET là lấy một số dữ liệu. Yêu cầu và lấy lại dữ liệu. POST nên được sử dụng cho các hoạt động CRUD khác hơn là tôi đọc. Nhưng khi nói đến nó, máy chủ có thực sự quan tâm nếu nó nhận được GET so với POST cuối cùng không?GET so với POST có thực sự quan trọng không?
Vì bạn là người viết phần mềm máy chủ (có lẽ), sau đó bạn quan tâm nếu bạn bảo nó cẩn thận. Nếu bạn xử lý dữ liệu POST và GET giống hệt nhau, thì không, nó sẽ không.
Tuy nhiên, trình duyệt chắc chắn quan tâm. Làm mới hoặc nhấp lại vào trang bạn nhận được dưới dạng phản hồi đối với POST sẽ bật lên chút ít, ví dụ: "Bạn có chắc chắn muốn gửi lại dữ liệu không".
Quan trọng hơn, bạn có thể sử dụng mẫu Gửi/Chuyển hướng/Nhận để ngăn mọi người vô tình làm lại các hành động. – Wedge
Tuy nhiên, điều đó có thể được thực hiện xung quanh nếu mã của bạn xử lý yêu cầu POST không bao giờ hiển thị bất kỳ thứ gì mà thay vào đó chuyển hướng đến một trang thực hiện. Xem http://en.wikipedia.org/wiki/Post/Redirect/Get –
Tất nhiên. Và đó là khá nhiều quan điểm của tôi. Từ quan điểm của trình duyệt, điều quan trọng là bạn gửi dữ liệu qua POST hoặc GET, và do đó chúng phải được xử lý khác nhau bởi máy chủ. Tuy nhiên, tôi sẽ không gọi nó là "giải pháp" vì điều đó ngụ ý rằng hành vi của trình duyệt là một lỗi. Nó hoạt động theo cách này vì một lý do hoàn hảo, và "cách giải quyết" là một cách hoàn toàn hợp lý để xử lý nó. – jalf
Nếu người dùng có thể đánh dấu trang kết quả? Một điều cần lưu ý là một số trình duyệt/máy chủ giới hạn không chính xác chiều dài GET URI.
Chỉnh sửa: lưu ý giới hạn độ dài ký tự được sửa lỗi - cảm ơn!
jbruce211: Đây là giới hạn dựa trên việc triển khai (ví dụ: trình duyệt hoặc máy chủ http). Nó không phải là giới hạn nội tại để GET cho mỗi thông số HTTP. Từ thông số: "Giao thức HTTP không đặt bất kỳ giới hạn nào trước đây về độ dài của URI. Máy chủ PHẢI có thể xử lý URI của bất kỳ tài nguyên nào mà chúng phân phối và NÊN có thể xử lý URI có độ dài không bị chặn nếu chúng cung cấp các biểu mẫu dựa trên GET có thể tạo các URI như vậy. " http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html – ars
Không, chúng không nên ngoại trừ các câu trả lời và tải lên tệp @ jbruce2112 yêu cầu POST.
GET có giới hạn ở phía trình duyệt. Ví dụ: some browsers giới hạn độ dài yêu cầu GET.
Tôi nghĩ câu trả lời phù hợp hơn, bạn có thể làm được những điều tương tự với cả hai. Tuy nhiên, đó không phải là vấn đề ưu tiên, nhưng là vấn đề sử dụng chính xác . Tôi sẽ khuyên bạn sử dụng bạn GET và POST như thế nào họ đã được dự định để được sử dụng.
Điều này xảy ra nếu công cụ tìm kiếm thu thập dữ liệu trang, vì chúng sẽ tạo yêu cầu GET nhưng không phải POST. Giả sử bạn có một liên kết trên trang của bạn:
http://www.example.com/items.aspx?id=5&mode=delete
Nếu không có một số loại kiểm tra uỷ quyền thực hiện trước khi xóa, nó có thể là Googlebot có thể come in and delete items từ trang của bạn.
Tuyệt vời tìm Brian, tôi đã tìm kiếm bài viết chính xác đó để liên kết! –
Ngay cả khi được ủy quyền, kẻ tấn công có thể gửi email với tới ai đó đã đăng nhập. –
Paco
@Paco: Nếu trình duyệt của bạn tải img, nó sẽ sử dụng GET. Máy chủ web KHÔNG nên thực hiện các hành động như "xóa" dựa trên yêu cầu GET vì chính xác lý do này. Trách nhiệm của máy chủ web là phải thực thi các hành động nghiêm trọng đó chỉ xảy ra thông qua các yêu cầu POST. – abelenky
Nó phụ thuộc vào phần mềm ở cuối máy chủ. Một số thư viện, như CGI.pm trong perl xử lý cả hai theo mặc định. Nhưng có những tình huống mà bạn ít nhiều phải sử dụng POST thay vì GET, ít nhất là để đẩy dữ liệu đến máy chủ. Số lượng lớn dữ liệu (trong đó Url GET tương ứng sẽ trở nên quá dài), dữ liệu nhị phân (để tránh nhiều sự cố mã hóa/giải mã), nhiều tệp, tiêu đề không phân tích cú pháp (để cập nhật liên tục kiểu AJAX trước ...) và tương tự .
Máy chủ kỹ thuật không thể quan tâm theo cách này hay cách khác về loại yêu cầu mà nó nhận được. Nó sẽ thực hiện một cách mù quáng bất kỳ yêu cầu nào đi qua dây.
Vấn đề là gì. Nếu bạn có hành động phá hủy hoặc sửa đổi dữ liệu trong hành động GET, Google sẽ xé trang web của bạn khi nó thu thập dữ liệu thông qua lập chỉ mục.
Máy chủ thường không quan tâm. Nhưng chủ yếu là để theo dõi các thực hành tốt, như bạn đã đề cập. Phía máy khách cũng quan trọng - như đã đề cập, bạn không thể đánh dấu trang POST được thường xuyên, và một số trình duyệt có giới hạn về độ dài của URL cho các truy vấn GET thực sự dài.
Nếu bạn sử dụng yêu cầu GET để thay đổi trạng thái kết thúc, bạn sẽ gặp rủi ro về những điều xấu xảy ra nếu trình thu thập thông tin của một số loại đi qua trang web của bạn.Quay trở lại khi wiki đầu tiên trở nên phổ biến, đã có những câu chuyện kinh dị của toàn bộ trang web bị xóa vì chức năng "xóa trang" đã được triển khai dưới dạng yêu cầu GET, với kết quả tai hại khi Googlebot phát ...
Vì GET được thiết kế cho xác định tài nguyên bạn muốn nhận, tùy thuộc vào phần mềm chính xác ở phía máy chủ, máy chủ web (hoặc bộ cân bằng tải trước mặt) có thể có giới hạn kích thước trên yêu cầu GET để ngăn chặn tấn công từ chối dịch vụ ...
" Sử dụng GET nếu: Tương tác giống như một câu hỏi (nghĩa là, nó là một hoạt động an toàn như truy vấn, đọc hoạt động hoặc tra cứu). "
"Sử dụng POST nếu: Tương tác giống như đơn đặt hàng hơn hoặc tương tác thay đổi trạng thái tài nguyên theo cách người dùng 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 cho kết quả tương tác. "
Theo RFC HTTP, GET không nên có bất kỳ tác dụng phụ, trong khi POST có thể có tác dụng phụ.
Ví dụ cơ bản nhất về điều này là GET không thích hợp cho bất kỳ thứ gì như giao dịch mua hoặc đăng bài viết lên blog, trong khi POST phù hợp với các hành động có hậu quả.
Bằng RFC, bạn có thể giữ người dùng chịu trách nhiệm về các hành động do POST thực hiện (chẳng hạn như mua hàng), nhưng không phải cho các hành động GET. 'Bots luôn sử dụng GET vì lý do này.
Từ RFC 2616, 9.1.1:
9.1.1 Phương pháp an toàn
implementors nên lưu ý rằng phần mềm đại diện cho người sử dụng trong
tương tác của chúng qua Internet, và nên cẩn thận để cho phép người dùng biết về bất kỳ hành động nào họ có thể thực hiện mà có thể có
u ý nghĩa bất ngờ đối với chính họ hoặc những người khác.Đặc biệt, quy ước đã được thành lập rằng GET và
phương pháp TRỤ KHÔNG NÊN có tầm quan trọng của thi một hành động
khác hơn là thu hồi. Những phương pháp này nên được coi là "an toàn". cho phép tác nhân người dùng đại diện cho các phương thức khác như POST, PUT và DELETE, theo cách đặc biệt để người dùng nhận thức được thực tế là hành động có thể không an toàn là .Đương nhiên, đó là không thể đảm bảo rằng các máy chủ không
tạo ra tác dụng phụ như là kết quả của thực hiện một yêu cầu GET; trên thực tế, một số tài nguyên động cho rằng tính năng . Sự khác biệt quan trọng ở đây là người dùng không yêu cầu các tác dụng phụ, do đó, do đó, không thể chịu trách nhiệm cho họ.
GET có những hạn chế giới hạn dữ liệu dựa trên trình duyệt gửi:
Các spec cho chiều dài URL không dictate tối thiểu hoặc chiều dài URL tối đa, nhưng việc thực hiện khác nhau tùy theo trình duyệt. Trên Windows: Opera hỗ trợ ~ 4050 ký tự, IE 4.0+ hỗ trợ chính xác 2083 ký tự, Netscape 3 -> 4.78 hỗ trợ lên đến 8192 ký tự trước khi gây ra lỗi khi tắt và Netscape 6 hỗ trợ ~ 2000 trước khi gây lỗi khi khởi động
Cũng có thể có giới hạn về yêu cầu GET ở phía máy chủ. Ví dụ: Apache có giới hạn mặc định được đặt là [8190 byte] (https://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline) –
Lưu ý rằng các trình duyệt có thể lưu trữ các yêu cầu GET nhưng thường sẽ không lưu các yêu cầu POST.
Theo thông số kỹ thuật HTTP, GET an toàn và không cần thiết và POST không phải là. Điều này có nghĩa là yêu cầu GET có thể được lặp lại nhiều lần mà không gây ra tác dụng phụ.
Ngay cả khi máy chủ của bạn không quan tâm (và điều này là không chắc), có thể có các tác nhân trung gian giữa khách hàng của bạn và máy chủ, tất cả đều có kỳ vọng này. Ví dụ: proxy cho dữ liệu bộ nhớ cache tại ISP của bạn hoặc các nhà cung cấp khác để cải thiện hiệu suất. Điều tương tự cũng đúng đối với các máy gia tốc, ví dụ như một plugin tìm nạp trước cho trình duyệt của bạn.
Do đó, yêu cầu GET có thể được lưu trong bộ nhớ cache (dựa trên các thông số nhất định) và nếu không thành công, nó có thể được tự động lặp lại mà không cần phải thực hiện bất kỳ tác hại nào. Vì vậy, thực sự máy chủ của bạn nên cố gắng hoàn thành hợp đồng này.
Mặt khác, POST không an toàn, không phải là idempotent và mọi tác nhân không biết lưu trữ kết quả của yêu cầu POST hoặc tự động thử lại yêu cầu POST. Vì vậy, ví dụ, một giao dịch thẻ tín dụng sẽ không bao giờ, bao giờ là một yêu cầu GET (bạn không muốn các tài khoản được ghi nợ nhiều lần vì các lỗi mạng, vv).
Đó là việc thực hiện rất cơ bản về điều này. Để biết thêm thông tin, bạn có thể xem cuốn sách "RESTful Web Services" của Ruby và Richardson (O'Reilly press).
Đối với một mất nhanh chóng về chủ đề của REST, hãy xem xét bài đăng này:
http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
Điều buồn cười là hầu hết mọi người tranh luận về giá trị của PUT v POST. Vấn đề GET v POST là và luôn được giải quyết rất tốt. Bỏ qua nó vì nguy hiểm của chính bạn.
Bạn nhận thức được một số khác biệt bảo mật tinh tế. Xem câu hỏi của tôi
Về cơ bản điều quan trọng cần nhớ là GET sẽ đi vào lịch sử trình duyệt và sẽ được truyền thông qua proxy trong văn bản đơn giản, do đó bạn không muốn bất kỳ thông tin nhạy cảm , giống như mật khẩu trong GET.
Rõ ràng có thể, nhưng đáng nói đến.
Vâng, nó quan trọng. GET và POST khá khác nhau, thực sự.
Bạn đang ở vị trí bình thường, GET là để lấy dữ liệu từ máy chủ và hiển thị trang, trong khi POST là để "đăng" dữ liệu trở lại máy chủ. Bên trong, các tập lệnh của bạn có cùng dữ liệu cho dù đó là GET hay POST, vì vậy không, máy chủ không thực sự quan tâm.
Sự khác biệt chính là các tham số GET được chỉ định trong URL, trong khi POST thì không. Đây là lý do POST được sử dụng cho các biểu mẫu đăng nhập và đăng nhập - bạn không muốn mật khẩu của mình trong URL. Tương tự, nếu bạn đang xem các trang khác nhau hoặc hiển thị một chế độ xem cụ thể của một số dữ liệu, bạn thường muốn có một URL duy nhất.
Không chuyển mật khẩu của bạn trong URL không phải là loại bảo mật, và không có cách nào để trải qua cuộc sống, con trai. (cười). Nếu bạn sử dụng văn bản thuần (HTTP so với HTTPS), mật khẩu của bạn sẽ hiển thị cho dù POST hoặc GET của nó. – abelenky
Tôi chưa bao giờ nói POST an toàn hơn, tôi nói bạn không muốn mật khẩu của mình trong một URL. Điều gì sẽ xảy ra nếu người dùng đăng URL đó trên diễn đàn hay gì đó? – DisgruntledGoat
Về mặt kỹ thuật, không. Tất cả GET làm là đăng nội dung trong dòng đầu tiên của yêu cầu HTTP và POST đăng nội dung trong phần nội dung.
Tuy nhiên, cách "cơ sở hạ tầng web" xử lý sự khác biệt tạo nên một thế giới khác biệt. Chúng tôi có thể viết một cuốn sách về nó. Tuy nhiên, tôi sẽ cung cấp cho bạn một số "phương pháp hay nhất":
Sử dụng "POST" khi yêu cầu HTTP của bạn thay đổi thứ "bê tông" bên trong máy chủ web. Tức là, bạn đang chỉnh sửa một trang, tạo một bản ghi mới, v.v. POSTS ít có khả năng được lưu trong bộ nhớ cache hoặc được coi là "có thể lặp lại mà không có tác dụng phụ"
Sử dụng "NHẬN" khi bạn muốn "xem một đối tượng". Bây giờ, một cái nhìn như vậy có thể thay đổi một cái gì đó "đằng sau hậu trường" trong điều khoản của bộ nhớ đệm hoặc lưu giữ hồ sơ, nhưng nó không nên thay đổi bất cứ điều gì "đáng kể". Tức là, tôi có thể lặp lại GET của tôi hơn và hơn và không có gì xấu sẽ xảy ra, ngoại trừ số lượt truy cập tăng cao. GET nên dễ dàng đánh dấu, do đó, người dùng có thể quay trở lại cùng một đối tượng sau này.
Các tham số cho GET (nội dung sau?, Theo truyền thống) phải được xem là "thuộc tính cho chế độ xem" hoặc "nội dung cần xem" v.v. Một lần nữa, nó không thực sự thay đổi bất cứ điều gì: sử dụng POST cho điều đó.
Và, một từ cuối cùng, khi bạn ĐĂNG một cái gì đó (ví dụ, bạn đang tạo một nhận xét mới), hãy xử lý cho bài đăng 302 để "chuyển hướng" người dùng đến URL mới xem đối tượng đó . Tức là, POST xử lý thông tin, sau đó chuyển hướng trình duyệt đến câu lệnh GET để xem trạng thái mới. Hiển thị thông tin là kết quả của POST cũng có thể gây ra sự cố. Thực hiện chuyển hướng thường được sử dụng và làm cho mọi thứ hoạt động tốt hơn.
"Về mặt kỹ thuật, không". Đây là một chút kỳ lạ. Ý tôi là, mọi thứ mà lập trình viên của chúng tôi làm là những thứ và số không vào cuối ngày, vì vậy "về mặt kỹ thuật", không có sự khác biệt giữa nhiều thứ! Tài liệu tham khảo có thẩm quyền ở đây là đặc tả HTTP (rfc 2616) tạo sự phân biệt kỹ thuật trong phần 9. – ars
ars: thật không may, những gì đặc tả HTTP không đề cập đến là ứng dụng nào (ví dụ, máy chủ web, kịch bản cgi, ứng dụng web DO) với thông tin đó. Điều này không thể được thu thập từ thông số HTTP. Vì vậy, theo spec, sự khác biệt duy nhất là cách thông tin được gửi đến máy chủ HTTP. Tùy thuộc vào người nhận (chương trình nhận dữ liệu) có thể có sự khác biệt ZERO giữa GET và POST, hoặc một thế giới khác biệt. Vì vậy, câu trả lời của tôi là "nếu bạn làm theo cách này, bạn sẽ gặp phải ít vấn đề hơn nếu bạn làm theo cách khác". –
Đọc thông số HTTP 1.1 có thể giúp bạn- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html – RichardOD
Tôi phải tự hỏi ... Tại sao câu hỏi này có 19 câu trả lời, khoảng 40 phiếu bầu cho các câu trả lời, và chỉ có một Up-Vote về câu hỏi (của tôi). Đó là một câu hỏi hay! Mọi người có lười biếng về các câu hỏi bỏ phiếu không? – abelenky
@abelenky - Tôi đã hết số phiếu bầu cho ngày hôm qua, đây là +1 cho ngày hôm nay –