Từ những gì tôi có thể thu thập, có ba loại:

1. Không bao giờ sử dụng GETvà sử dụngPOST
2. Không bao giờ sử dụng POSTvà sử dụngGET
3. Không quan trọng bạn sử dụng cái nào.

Tôi có đúng khi giả sử ba trường hợp đó không? Nếu vậy, một số ví dụ từ mỗi trường hợp là gì?

Sử dụng POSTcho các hành động phá hoại như sáng tạo (tôi biết về sự trớ trêu), chỉnh sửa và xóa, vì bạn không thể nhấn một POSThành động trong thanh địa chỉ của trình duyệt. Sử dụng GETkhi an toàn để cho phép một người gọi hành động. Vì vậy, một URL như:

http://myblog.org/admin/posts/delete/357

Sẽ đưa bạn đến một trang xác nhận, thay vì chỉ đơn giản là xóa các mục. Cách này dễ dàng hơn để tránh tai nạn theo cách này.

POSTcũng an toàn hơn GET, bởi vì bạn không dán thông tin vào một URL. Và vì vậy, sử dụng GETnhư methodmột biểu mẫu HTML thu thập mật khẩu hoặc thông tin nhạy cảm khác không phải là ý tưởng tốt nhất.

Một lưu ý cuối cùng: POSTcó thể truyền một lượng thông tin lớn hơn GET. 'POST' không có giới hạn kích thước đối với dữ liệu được truyền, trong khi 'GET' được giới hạn ở 2048 ký tự.

Tóm lại

• Sử dụng GETcho safe andidempotentcác yêu cầu
• Sử dụng POSTcho neither safe nor idempotentcác yêu cầu

Trong chi tiết Có một nơi thích hợp cho mỗi. Ngay cả khi bạn không tuân theo các nguyên tắc RESTful , có thể thu được rất nhiều từ việc tìm hiểu về REST và cách tiếp cận theo hướng tài nguyên hoạt động.

Một ứng dụng RESTful sẽ use GETscho các hoạt động là cả hai safe and idempotent.

Một safehoạt động là một hoạt động không not change the datayêu cầu.

Một idempotenthoạt động là một trong đó kết quả sẽ cho be the samedù bạn yêu cầu bao nhiêu lần.

Lý do là, vì các GET được sử dụng cho các hoạt động an toàn, chúng cũng tự động là idempotent . Thông thường, một GET được sử dụng để truy xuất tài nguyên (một câu hỏi và các câu trả lời liên quan của nó về tràn ngăn xếp chẳng hạn) hoặc bộ sưu tập tài nguyên.

Một ứng dụng RESTful sẽ sử dụng PUTscho các hoạt động not safe but idempotent.

Tôi biết câu hỏi là về GET và POST, nhưng tôi sẽ quay lại POST sau một giây.

Thông thường, PUT được sử dụng để chỉnh sửa tài nguyên (ví dụ chỉnh sửa câu hỏi hoặc câu trả lời về lỗi tràn ngăn xếp).

A POSTsẽ được sử dụng cho bất kỳ hoạt động nào neither safe or idempotent.

Thông thường, POST sẽ được sử dụng để tạo tài nguyên mới, ví dụ như tạo câu hỏi SO MỚI (mặc dù trong một số thiết kế, PUT cũng sẽ được sử dụng cho việc này).

Nếu bạn chạy POST hai lần, cuối cùng bạn sẽ tạo ra HAI câu hỏi mới.

Ngoài ra còn có một hoạt động XÓA, nhưng tôi đoán tôi có thể để nó ở đó :)

Thảo luận

Về mặt thực tế, các trình duyệt web hiện đại thường chỉ hỗ trợ GET và POST một cách đáng tin cậy (bạn có thể thực hiện tất cả các thao tác này thông qua các cuộc gọi javascript, nhưng về mặt nhập dữ liệu trong các biểu mẫu và nhấn gửi bạn thường có hai tùy chọn). Trong một ứng dụng RESTful, POST thường sẽ được ghi đè để cung cấp các lệnh gọi PUT và DELETE.

Nhưng, ngay cả khi bạn không tuân theo các nguyên tắc RESTful, việc suy nghĩ về việc sử dụng GET để truy xuất / xem thông tin và POST để tạo / chỉnh sửa thông tin có thể hữu ích.

Bạn không bao giờ nên sử dụng GET cho một hoạt động làm thay đổi dữ liệu. Nếu một công cụ tìm kiếm thu thập một liên kết đến op ác của bạn hoặc đánh dấu trang của khách hàng thì nó có thể gây ra rắc rối lớn.

Sử dụng GET nếu bạn không nhớ yêu cầu được lặp lại (Đó là trạng thái không thay đổi).

Sử dụng POST nếu hoạt động không thay đổi trạng thái của hệ thống.

Phiên bản ngắn

NHẬN: Thường được sử dụng cho các yêu cầu tìm kiếm đã gửi hoặc bất kỳ yêu cầu nào mà bạn muốn người dùng có thể kéo lên trang chính xác một lần nữa.

Ưu điểm của GET:

• URL có thể được đánh dấu an toàn.
• Các trang có thể được tải lại một cách an toàn.

Nhược điểm của GET:

• Các biến được truyền qua url dưới dạng cặp giá trị tên. (Rủi ro bảo mật)
• Số lượng biến có thể được thông qua. (Dựa trên trình duyệt. Ví dụ: Internet Explorer bị giới hạn ở 2.048 ký tự. )

POST: Được sử dụng cho các yêu cầu bảo mật cao hơn, nơi dữ liệu có thể được sử dụng để thay đổi cơ sở dữ liệu hoặc trang mà bạn không muốn ai đó đánh dấu.

Ưu điểm của POST:

• Các cặp tên-giá trị không được hiển thị trong url. (Bảo mật + = 1)
• Không giới hạn số lượng cặp giá trị tên thông qua POST. Tài liệu tham khảo.

Nhược điểm của POST:

• Trang đã sử dụng dữ liệu POST không thể được đánh dấu. (Nếu bạn mong muốn.)

Phiên bản dài hơn

Trực tiếp từ Giao thức truyền siêu văn bản - HTTP / 1.1 :

9.3 NHẬN

Phương thức GET có nghĩa là lấy bất kỳ thông tin nào (dưới dạng thực thể) được xác định bởi URI yêu cầu. Nếu URI yêu cầu đề cập đến một quy trình sản xuất dữ liệu, thì đó là dữ liệu được tạo sẽ được trả về làm thực thể trong phản hồi và không phải là văn bản nguồn của quy trình, trừ khi văn bản đó là đầu ra của quy trình.

Các ngữ nghĩa của phương thức GET thay đổi thành "GET có điều kiện" nếu thông báo yêu cầu bao gồm trường tiêu đề If-Modified-Because, If-Unmodified-Because, If-Match, If-none-Match hoặc If-Range. Phương thức GET có điều kiện yêu cầu thực thể chỉ được chuyển trong các trường hợp được mô tả bởi (các) trường tiêu đề có điều kiện. Phương thức GET có điều kiện nhằm giảm việc sử dụng mạng không cần thiết bằng cách cho phép các thực thể được lưu trong bộ nhớ cache được làm mới mà không yêu cầu nhiều yêu cầu hoặc truyền dữ liệu đã được giữ bởi máy khách.

Các ngữ nghĩa của phương thức GET thay đổi thành "GET một phần" nếu thông báo yêu cầu bao gồm trường tiêu đề Phạm vi. Một phần GET yêu cầu chỉ một phần của thực thể được chuyển, như được mô tả trong phần 14,35. Phương thức GET một phần nhằm giảm việc sử dụng mạng không cần thiết bằng cách cho phép các thực thể được truy xuất một phần được hoàn thành mà không cần truyền dữ liệu do khách hàng nắm giữ.

Phản hồi cho yêu cầu GET có thể được lưu trong bộ nhớ cache khi và chỉ khi nó đáp ứng các yêu cầu cho bộ đệm HTTP được mô tả trong phần 13.

Xem phần 15.1.3 để xem xét bảo mật khi được sử dụng cho các biểu mẫu.

9,5 BÀI ĐĂNG

Phương thức POST được sử dụng để yêu cầu máy chủ gốc chấp nhận thực thể được đính kèm trong yêu cầu dưới dạng cấp dưới mới của tài nguyên được xác định bởi URI yêu cầu trong Dòng yêu cầu. POST được thiết kế để cho phép một phương thức thống nhất bao gồm các chức năng sau:

• Chú thích các tài nguyên hiện có;

• Đăng một tin nhắn đến một bảng thông báo, nhóm tin tức, danh sách gửi thư hoặc nhóm bài viết tương tự;

• Cung cấp một khối dữ liệu, chẳng hạn như kết quả của việc gửi biểu mẫu, cho quy trình xử lý dữ liệu;

• Mở rộng cơ sở dữ liệu thông qua một hoạt động chắp thêm.

Hàm thực tế được thực hiện bởi phương thức POST được xác định bởi máy chủ và thường phụ thuộc vào URI yêu cầu. Thực thể được đăng phụ thuộc vào URI đó giống như cách một tệp phụ thuộc vào một thư mục chứa nó, một bài viết tin tức phụ thuộc vào một nhóm tin được đăng hoặc một bản ghi phụ thuộc vào cơ sở dữ liệu.

Hành động được thực hiện bởi phương thức POST có thể không dẫn đến một tài nguyên có thể được xác định bởi một URI. Trong trường hợp này, 200 (OK) hoặc 204 (Không có nội dung) là trạng thái phản hồi phù hợp, tùy thuộc vào việc phản hồi có bao gồm thực thể mô tả kết quả hay không.

Điều quan trọng đầu tiên là ý nghĩa của GET so với POST:

• GET nên được sử dụng để ... lấy ... một số thông tin từ máy chủ,
• trong khi POST nên được sử dụng để gửi một số thông tin đến máy chủ.

Sau đó, một vài điều có thể được lưu ý:

• Sử dụng GET, người dùng của bạn có thể sử dụng nút "quay lại" trong trình duyệt của họ và họ có thể đánh dấu các trang
• Có giới hạn về kích thước của các tham số bạn có thể vượt qua là GET (2KB cho một số phiên bản Internet Explorer, nếu tôi không nhầm) ; giới hạn là nhiều hơn cho POST và thường phụ thuộc vào cấu hình của máy chủ.

Dù sao, tôi không nghĩ rằng chúng ta có thể "sống" mà không có GET: nghĩ về số lượng URL bạn đang sử dụng với các tham số trong chuỗi truy vấn, mỗi ngày - không có GET, tất cả những URL đó sẽ không hoạt động ;-)

Ngoài sự khác biệt về độ dài trong nhiều trình duyệt web, còn có sự khác biệt về ngữ nghĩa. Các GET được coi là "an toàn" ở chỗ chúng là các hoạt động chỉ đọc không thay đổi trạng thái máy chủ. POST thường sẽ thay đổi trạng thái và sẽ đưa ra cảnh báo về việc gửi lại. Trình thu thập dữ liệu web của công cụ tìm kiếm có thể tạo GET nhưng không bao giờ nên tạo POST.

Sử dụng GET nếu bạn muốn đọc dữ liệu mà không thay đổi trạng thái và sử dụng POST nếu bạn muốn cập nhật trạng thái trên máy chủ.

Nguyên tắc chung của tôi là sử dụng Nhận khi bạn đang yêu cầu máy chủ không thay đổi trạng thái. Bài viết được dành riêng cho các yêu cầu đến máy chủ thay đổi trạng thái.

Một sự khác biệt thực tế là trình duyệt và máy chủ web có giới hạn về số lượng ký tự có thể tồn tại trong một URL. Nó khác với ứng dụng này đến ứng dụng khác, nhưng chắc chắn có thể đạt được nó nếu bạn có textareatrong biểu mẫu của mình.

Một Gotcha khác với GET - chúng được lập chỉ mục bởi các công cụ tìm kiếm và các hệ thống tự động khác. Google đã từng có một sản phẩm sẽ tìm nạp trước các liên kết trên trang bạn đang xem, vì vậy chúng sẽ tải nhanh hơn nếu bạn nhấp vào các liên kết đó. Nó gây ra sự tàn phá lớn trên các trang web có liên kết như delete.php?id=1- mọi người mất toàn bộ trang web của họ.

Sử dụng GET khi bạn muốn URL phản ánh trạng thái của trang. Điều này hữu ích để xem các trang được tạo động, chẳng hạn như những trang được xem ở đây. POST nên được sử dụng trong một hình thức để gửi dữ liệu, như khi tôi nhấp vào nút "Đăng câu trả lời của bạn". Nó cũng tạo ra một URL sạch hơn vì nó không tạo ra một chuỗi tham số sau đường dẫn.

Vì GET là các URL hoàn toàn, chúng có thể được trình duyệt web lưu vào bộ nhớ cache và có thể được sử dụng tốt hơn cho những thứ như hình ảnh được tạo liên tục. (Đặt thời gian hết hạn)

Một ví dụ từ trang gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid

GET có thể mang lại hiệu suất tốt hơn một chút, một số máy chủ web ghi nội dung POST vào một tệp tạm thời trước khi gọi trình xử lý.

Một điều khác cần xem xét là giới hạn kích thước. GET được giới hạn bởi kích thước của URL, 1024 byte theo tiêu chuẩn, mặc dù các trình duyệt có thể hỗ trợ nhiều hơn.

Truyền nhiều dữ liệu hơn nên sử dụng POST để có khả năng tương thích trình duyệt tốt hơn.

Thậm chí ít hơn giới hạn đó là một vấn đề, như một poster khác đã viết, mọi thứ trong URL có thể kết thúc ở các phần khác của giao diện người dùng, như lịch sử.

Không có gì bạn không thể làm mỗi lần. Vấn đề là bạn không cần phải sửa đổi trạng thái máy chủ trên HTTP GET. Proxy HTTP cho rằng vì HTTP GET không sửa đổi trạng thái nên việc người dùng gọi HTTP GET một lần hay 1000 lần không có sự khác biệt. Sử dụng thông tin này, họ cho rằng việc trả lại phiên bản được lưu trong bộ đệm HTTP GET đầu tiên là an toàn. Nếu bạn phá vỡ đặc tả HTTP, bạn có nguy cơ phá vỡ ứng dụng khách HTTP và proxy trong tự nhiên. Đừng làm vậy :)

Điều này đi sâu vào khái niệm REST và cách thức sử dụng web. Có một podcast tuyệt vời trên đài phát thanh Kỹ thuật phần mềm giúp nói chuyện chuyên sâu về việc sử dụng Nhận và Đăng.

Get được sử dụng để lấy dữ liệu từ máy chủ, trong đó không cần thực hiện hành động cập nhật. Ý tưởng là bạn sẽ có thể sử dụng cùng một yêu cầu GET và trả lại cùng một thông tin. URL có thông tin nhận được trong chuỗi truy vấn, vì nó có nghĩa là có thể dễ dàng gửi đến các hệ thống khác và mọi người thích một địa chỉ để tìm thứ gì đó.

Bài viết được cho là được sử dụng (ít nhất là theo kiến ​​trúc REST mà web dựa trên) để đẩy thông tin đến máy chủ / yêu cầu máy chủ thực hiện một hành động. Ví dụ như: Cập nhật dữ liệu này, Tạo bản ghi này.

1.3 Danh sách kiểm tra nhanh để chọn HTTP GEThoặcPOST

Sử dụng GET nếu:

    The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

Sử dụng POST nếu:

    The interaction is more like an order, or
    The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
    The user be held accountable for the results of the interaction.

Nguồn .

Tôi không thấy vấn đề gì khi sử dụng get, tôi sử dụng nó cho những điều đơn giản trong đó có ý nghĩa để giữ mọi thứ trên chuỗi truy vấn.

Sử dụng nó để cập nhật trạng thái - như NHẬN delete.php?id=5để xóa một trang - rất rủi ro. Mọi người phát hiện ra rằng khi trình tăng tốc web của Google bắt đầu tìm nạp URL trên các trang - nó đánh vào tất cả các liên kết 'xóa' và xóa sạch dữ liệu của mọi người. Điều tương tự có thể xảy ra với nhện công cụ tìm kiếm.

POST có thể di chuyển dữ liệu lớn trong khi GET không thể.

Nhưng nhìn chung, đó không phải là về một sự thiếu sót của GET, mà là một quy ước nếu bạn muốn trang web / ứng dụng web của bạn hoạt động tốt.

Hãy xem http://www.w3.org/2001/tag/doc/whenToUseGet.html

Từ RFC 2616 :

9.3 NHẬN
Phương thức GET có nghĩa là lấy bất kỳ thông tin nào (dưới dạng thực thể) được xác định bởi URI yêu cầu. Nếu URI yêu cầu đề cập đến một quy trình sản xuất dữ liệu, thì đó là dữ liệu được tạo sẽ được trả về làm thực thể trong phản hồi và không phải là văn bản nguồn của quy trình, trừ khi văn bản đó là đầu ra của quy trình.

9.5 POST
Phương thức POST được sử dụng để yêu cầu máy chủ gốc chấp nhận thực thể được đính kèm trong yêu cầu dưới dạng cấp dưới mới của tài nguyên được xác định bởi URI yêu cầu trong Dòng yêu cầu. POST được thiết kế để cho phép một phương thức thống nhất bao gồm các chức năng sau:

• Chú thích các tài nguyên hiện có;
• Đăng một tin nhắn đến một bảng thông báo, nhóm tin tức, danh sách gửi thư hoặc nhóm bài viết tương tự;
• Cung cấp một khối dữ liệu, chẳng hạn như kết quả của việc gửi biểu mẫu, cho quy trình xử lý dữ liệu;
• Mở rộng cơ sở dữ liệu thông qua một hoạt động chắp thêm.

Hàm thực tế được thực hiện bởi phương thức POST được xác định bởi máy chủ và thường phụ thuộc vào URI yêu cầu. Thực thể được đăng phụ thuộc vào URI đó giống như cách một tệp phụ thuộc vào một thư mục chứa nó, một bài viết tin tức phụ thuộc vào một nhóm tin được đăng hoặc một bản ghi phụ thuộc vào cơ sở dữ liệu.

Hành động được thực hiện bởi phương thức POST có thể không dẫn đến một tài nguyên có thể được xác định bởi một URI. Trong trường hợp này, 200 (OK) hoặc 204 (Không có nội dung) là trạng thái phản hồi phù hợp, tùy thuộc vào việc phản hồi có bao gồm thực thể mô tả kết quả hay không.

Tôi sử dụng POST khi tôi không muốn mọi người thấy QueryString hoặc khi QueryString lớn. Ngoài ra, POST là cần thiết để tải lên tập tin.

Mặc dù vậy, tôi không thấy vấn đề gì khi sử dụng GET, tôi sử dụng nó cho những điều đơn giản trong đó có ý nghĩa để giữ mọi thứ trên QueryString.

Sử dụng GET sẽ cho phép liên kết đến một trang cụ thể có thể trong đó POST sẽ không hoạt động.

Mục đích ban đầu là GET được sử dụng để lấy lại dữ liệu và POST là bất cứ điều gì. Nguyên tắc nhỏ mà tôi sử dụng là nếu tôi gửi bất cứ thứ gì trở lại máy chủ, tôi sử dụng POST. Nếu tôi chỉ gọi một URL để lấy lại dữ liệu, tôi sử dụng GET.

Đọc bài viết về HTTP trong Wikipedia . Nó sẽ giải thích giao thức là gì và nó làm gì:

ĐƯỢC

Yêu cầu một đại diện của tài nguyên được chỉ định. Lưu ý rằng không nên sử dụng GET cho các hoạt động gây ra tác dụng phụ, chẳng hạn như sử dụng nó để thực hiện các hành động trong các ứng dụng web. Một lý do cho điều này là GET có thể được sử dụng tùy ý bởi robot hoặc trình thu thập thông tin, không cần phải xem xét các tác dụng phụ mà yêu cầu sẽ gây ra.

và

POST Gửi dữ liệu sẽ được xử lý (ví dụ: từ biểu mẫu HTML) sang tài nguyên đã xác định. Dữ liệu được bao gồm trong phần thân của yêu cầu. Điều này có thể dẫn đến việc tạo ra một tài nguyên mới hoặc cập nhật các tài nguyên hiện có hoặc cả hai.

W3C có một tài liệu có tên URI, Địa chỉ và việc sử dụng HTTP GET và POST giải thích khi nào nên sử dụng cái gì. Trích dẫn

1.3 Danh sách kiểm tra nhanh để chọn HTTP GET hoặc POST

• Sử dụng GET nếu:
  • Sự 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).

và

• 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 o Người dùng phải chịu trách nhiệm về kết quả của sự tương tác.

Tuy nhiên, trước khi quyết định cuối cùng sử dụng HTTP GET hoặc POST, vui lòng xem xét các cân nhắc đối với dữ liệu nhạy cảm và các cân nhắc thực tế.

Một ví dụ thực tế sẽ là bất cứ khi nào bạn gửi biểu mẫu HTML. Bạn chỉ định bài đăng hoặc nhận cho hành động biểu mẫu. PHP sẽ điền $ _GET và $ _POST tương ứng.

Trong PHP, POSTgiới hạn dữ liệu thường được đặt bởi bạn php.ini. GETtôi tin rằng bị giới hạn bởi cài đặt máy chủ / trình duyệt - thường là xung quanh 255byte.

Từ w3schools.com :

HTTP là gì?

Giao thức truyền siêu văn bản (HTTP) được thiết kế để cho phép liên lạc giữa máy khách và máy chủ.

HTTP hoạt động như một giao thức đáp ứng yêu cầu giữa máy khách và máy chủ.

Trình duyệt web có thể là máy khách và ứng dụng trên máy tính lưu trữ trang web có thể là máy chủ.

Ví dụ: Một máy khách (trình duyệt) gửi yêu cầu HTTP đến máy chủ; sau đó máy chủ trả về phản hồi cho máy khách. Phản hồi chứa thông tin trạng thái về yêu cầu và cũng có thể chứa nội dung được yêu cầu.

Hai phương thức yêu cầu HTTP: GET và POST

Hai phương thức thường được sử dụng cho phản hồi yêu cầu giữa máy khách và máy chủ là: GET và POST.

NHẬN - Yêu cầu dữ liệu từ một tài nguyên được chỉ định POST - Gửi dữ liệu được xử lý đến một tài nguyên được chỉ định

Ở đây chúng tôi phân biệt sự khác biệt chính:

Phiên bản đơn giản của POST GET PUT DELETE

• sử dụng GET - khi bạn muốn nhận bất kỳ tài nguyên nào như Danh sách dữ liệu dựa trên bất kỳ Id hoặc Tên nào
• sử dụng POST - khi bạn muốn gửi bất kỳ dữ liệu nào đến máy chủ. Hãy nhớ rằng POST là hoạt động có trọng lượng lớn vì để cập nhật, chúng ta nên sử dụng PUT thay vì POST trong nội bộ POST sẽ tạo tài nguyên mới
• sử dụng PUT - khi bạn

Vâng, một điều quan trọng là bất cứ điều gì bạn gửi qua GETsẽ được hiển thị thông qua URL. Thứ hai như Ceejayoz nói, có giới hạn về ký tự cho một URL.

Một điểm khác biệt nữa là POST thường yêu cầu hai thao tác HTTP, trong khi GET chỉ yêu cầu một thao tác.

Chỉnh sửa: Tôi nên làm rõ - cho các mẫu lập trình phổ biến. Nói chung, việc trả lời POST bằng một trang web HTML ngay lập tức là một thiết kế đáng ngờ vì nhiều lý do, một trong số đó là sự khó chịu "bạn phải gửi lại biểu mẫu này, bạn có muốn làm như vậy không?" nhấn nút quay lại.

Như đã được trả lời bởi những người khác, có giới hạn về kích thước url với get và các tệp chỉ có thể được gửi bằng bài đăng.

Tôi muốn thêm rằng người ta có thể thêm mọi thứ vào cơ sở dữ liệu bằng cách lấy và thực hiện các hành động với một bài đăng. Khi một kịch bản nhận được một bài đăng hoặc nhận, nó có thể làm bất cứ điều gì tác giả muốn nó làm. Tôi tin rằng sự thiếu hiểu biết đến từ cách mà cuốn sách đã chọn hoặc cách bạn đọc nó.

Một tác giả kịch bản nên sử dụng các bài đăng để thay đổi cơ sở dữ liệu và chỉ sử dụng get để lấy thông tin.

Các ngôn ngữ script cung cấp nhiều phương tiện để truy cập yêu cầu. Ví dụ, PHP cho phép sử dụng $_REQUESTđể truy xuất một bài đăng hoặc nhận. Người ta nên tránh điều này để ủng hộ cụ thể hơn $_GEThoặc $_POST.

Trong lập trình web, có rất nhiều chỗ để diễn giải. Có những gì nên làm và những gì một người có thể làm, nhưng cái nào tốt hơn thường được đưa ra để tranh luận. May mắn thay, trong trường hợp này, không có sự mơ hồ. Bạn nên sử dụng bài viết để thay đổi dữ liệu và bạn nên sử dụng get để lấy thông tin.

Gorgapor, mod_rewritevẫn thường sử dụng GET. Nó chỉ cho phép dịch một URL thân thiện hơn thành một URL với một GETchuỗi truy vấn.

Dữ liệu Bài đăng HTTP không có giới hạn được chỉ định về lượng dữ liệu, trong đó các trình duyệt khác nhau có các giới hạn khác nhau cho GET. RFC 2068 tuyên bố:

Máy chủ nên thận trọng tùy thuộc vào độ dài URI trên 255 byte, bởi vì một số triển khai proxy hoặc máy khách cũ hơn có thể không hỗ trợ chính xác các độ dài này

Cụ thể, bạn nên xây dựng các cấu trúc HTTP phù hợp cho những gì chúng được sử dụng cho. HTTP GET không nên có tác dụng phụ và có thể được làm mới và lưu trữ an toàn bởi HTTP Proxy, v.v.

HTTP POST được sử dụng khi bạn muốn gửi dữ liệu theo tài nguyên url.

Một ví dụ điển hình cho việc sử dụng HTTP GET là trên Tìm kiếm, tức là Tìm kiếm? Truy vấn = truy vấn của tôi + Một ví dụ điển hình cho việc sử dụng HTTP POST là gửi phản hồi cho biểu mẫu trực tuyến.