Sự cần thiết của các phương thức như GET và POST trong giao thức HTTP là gì?

Chúng ta có thể không thực hiện giao thức HTTP chỉ bằng cách sử dụng phần thân yêu cầu và phần thân phản hồi không?

Ví dụ: URL sẽ chứa yêu cầu, sẽ được ánh xạ tới một chức năng tùy thuộc vào ngôn ngữ lập trình ở phía máy chủ cho biết một Servlet và phản hồi HTML và JavaScript sẽ được gửi qua.

Tại sao giao thức HTTP có khái niệm về các phương thức?

Từ các câu trả lời, tôi hiểu được lý do tại sao khái niệm phương pháp lại có .. Điều này dẫn đến một câu hỏi liên quan khác:

Ví dụ: trong liên kết soạn thư gmail, yêu cầu và dữ liệu PUT / POST sẽ được gửi. Làm thế nào để trình duyệt biết phương pháp sử dụng? Trang gmail được gửi bởi máy chủ có bao gồm tên phương thức sẽ sử dụng khi gọi yêu cầu soạn gmail không? Khi chúng tôi gọi www.gmail.com, nó phải sử dụng phương thức GET, làm thế nào để trình duyệt biết rằng phương thức này sẽ sử dụng?

Tái bút : Tôi không có đủ tín dụng để nhận xét về câu trả lời, vì vậy tôi không thể nhận xét về nhiều câu hỏi được đưa ra bởi những người liên quan đến ý định đằng sau câu hỏi này.

Như một số câu trả lời cho biết, chúng tôi có thể tạo người dùng mới bằng phương pháp XÓA, sau đó điều này đặt ra câu hỏi về ý định đằng sau khái niệm phương thức trong giao thức http, bởi vì vào cuối ngày, nó hoàn toàn phụ thuộc vào máy chủ mà họ muốn ánh xạ URL tới . Tại sao khách hàng nên nói với máy chủ những phương pháp sử dụng cho URL.

Xin lưu ý rằng câu hỏi đã thay đổi / được làm rõ vì câu trả lời này được viết lần đầu tiên. Một câu trả lời tiếp theo cho lần lặp mới nhất của câu hỏi là sau quy tắc ngang thứ hai

Sự cần thiết của các phương thức như GET và POST trong giao thức HTTP là gì?

Chúng, cùng với một vài thứ khác như định dạng tiêu đề, quy tắc về cách tách phần đầu và phần thân, tạo thành cơ sở của giao thức HTTP

Chúng ta có thể không thực hiện giao thức HTTP chỉ bằng cách sử dụng phần thân yêu cầu và phần thân phản hồi không?

Không, bởi vì bất cứ điều gì bạn tạo ra sẽ không phải là giao thức HTTP

Ví dụ: URL sẽ chứa yêu cầu, sẽ được ánh xạ tới một chức năng tùy thuộc vào ngôn ngữ lập trình ở phía máy chủ cho biết một Servlet và phản hồi HTML và JavaScript sẽ được gửi qua.

Xin chúc mừng, bạn vừa phát minh ra một giao thức mới! Bây giờ, nếu bạn muốn thiết lập một cơ quan tiêu chuẩn để lái và duy trì nó, phát triển nó, v.v., nó có thể vượt qua HTTP một ngày

Tôi đánh giá cao điều này hơi khó hiểu, nhưng không có gì kỳ diệu về internet, TCP / IP hoặc giao tiếp diễn ra giữa các máy chủ và máy khách. Bạn mở một kết nối và gửi một số từ xuống dây, tạo thành một cuộc trò chuyện. Cuộc trò chuyện thực sự cần phải tuân thủ một số thông số đã được phê chuẩn ở cả hai đầu nếu các yêu cầu được hiểu và phản hồi hợp lý được gửi. Điều này không khác với bất kỳ hộp thoại nào trên thế giới. Bạn nói tiếng Anh, hàng xóm của bạn nói tiếng Trung Quốc. Hy vọng rằng bàn tay của bạn vẫy, chỉ và lắc nắm tay sẽ đủ để truyền tải thông điệp của bạn rằng bạn không muốn anh ấy đỗ xe trước nhà bạn.

Quay lại internet, nếu bạn mở một ổ cắm cho máy chủ web tuân thủ HTTP và gửi thông tin sau:

EHLO
AUTH LOGIN

(Bắt đầu truyền email qua email) sau đó bạn sẽ không nhận được câu trả lời hợp lý. Bạn có thể tạo ra máy khách tuân thủ SMTP hoàn hảo nhất, nhưng máy chủ web của bạn sẽ không nói chuyện với nó bởi vì cuộc trò chuyện này là tất cả về giao thức được chia sẻ - không có giao thức được chia sẻ, không có niềm vui.

Đây là lý do tại sao bạn không thể thực hiện giao thức HTTP mà không thực hiện giao thức HTTP; nếu những gì bạn viết không phù hợp với giao thức, thì đơn giản đó không phải là giao thức - đó là một thứ khác và nó sẽ không hoạt động như được chỉ định trong giao thức

Nếu chúng tôi chạy với ví dụ của bạn một lát; nơi khách hàng kết nối và chỉ nêu một cái gì đó trông giống như một URL .. Và máy chủ hiểu nó và chỉ cần gửi một cái gì đó trông giống như HTML / JS (một trang web) thì chắc chắn, nó có thể hoạt động. Bạn đã tiết kiệm những gì mặc dù? Vài byte không nói NHẬN? Ít nhiều hơn về việc bỏ các tiêu đề phiền phức đó .. Máy chủ cũng đã lưu một số - nhưng nếu bạn không thể tìm ra những gì nó đã gửi cho bạn thì sao? Điều gì sẽ xảy ra nếu bạn yêu cầu một URL kết thúc bằng JPEG và nó đã gửi cho bạn một số byte tạo ra một hình ảnh, nhưng nó ở dạng PNG? Một PNG không đầy đủ ở đó. Giá như chúng ta có một tiêu đề cho biết nó sẽ có bao nhiêu byteđể gửi, sau đó chúng tôi sẽ biết liệu số byte chúng tôi nhận được có thực sự là toàn bộ tệp hay không. Điều gì sẽ xảy ra nếu máy chủ nén lại phản hồi để tiết kiệm băng thông nhưng không cho bạn biết? Bạn sẽ dành một số sức mạnh tính toán đáng kể để cố gắng tìm ra những gì nó đã gửi.

Vào cuối ngày, chúng ta cần siêu dữ liệu - thông tin về thông tin; chúng ta cần tiêu đề; chúng ta cần tập tin để có tên, phần mở rộng, ngày tạo. Chúng tôi cần mọi người tổ chức sinh nhật, nói vui lòng và cảm ơn, v.v. - thế giới có đầy đủ các giao thức và bit thông tin về bối cảnh vì vậy chúng tôi không phải ngồi xuống và làm việc mọi lúc mọi nơi. Nó tốn một chút dung lượng lưu trữ, nhưng nó dễ dàng đáng giá

Là thực hiện các phương thức HTTP khác nhau thực sự cần thiết?

Có thể cho rằng, người ta không phải thực hiện toàn bộ giao thức được chỉ định và điều này thường đúng với mọi thứ. Tôi không biết từng từ trong tiếng Anh; Hàng xóm Trung Quốc của tôi cũng là một nhà phát triển phần mềm nhưng trong một ngành khác và anh ta thậm chí không biết tiếng Trung Quốc đối với một số thuật ngữ được sử dụng trong ngành của tôi chứ đừng nói đến tiếng Anh. Mặc dù vậy, điều tốt là chúng ta có thể chọn một tài liệu về việc triển khai HTTP, anh ta có thể viết máy chủ và tôi có thể viết máy khách, bằng các ngôn ngữ lập trình khác nhau trên các kiến ​​trúc khác nhau và chúng vẫn hoạt động vì chúng tuân thủ giao thức

Đây có thể là trường hợp không ai trong số những người dùng của bạn sẽ phát hành bất cứ điều gì ngoài yêu cầu GET, sẽ không sử dụng các kết nối liên tục, gửi bất cứ thứ gì ngoài JSON làm cơ thể hoặc cần chấp nhận bất cứ điều gì ngoài văn bản / thuần túy để bạn có thể viết một máy chủ web thực sự giảm xuống chỉ đáp ứng nhu cầu rất hạn chế của trình duyệt máy khách. Nhưng bạn không thể tự ý quyết định loại bỏ các quy tắc cơ bản làm cho "một số văn bản truyền xuống ổ cắm" HTTP là gì; bạn không thể bỏ ý niệm cơ bản rằng yêu cầu sẽ là một chuỗi như:

VERB URL VERSION
header: value

maybe_body

Và phản hồi sẽ có một phiên bản, mã trạng thái và có thể là các tiêu đề. Nếu bạn thay đổi bất kỳ điều nào trong số đó - đó không phải là HTTP nữa - đó là một thứ khác và sẽ chỉ hoạt động với thứ được thiết kế để hiểu nó. HTTP là những gì theo định nghĩa này, vì vậy nếu bạn muốn thực hiện nó, bạn phải tuân theo các định nghĩa

Cập nhật

Câu hỏi của bạn đã phát triển một chút, đây là một số câu trả lời cho những gì bạn hỏi:

Tại sao giao thức HTTP có khái niệm về các phương thức?

Về mặt lịch sử, bạn cần đánh giá cao rằng mọi thứ không linh hoạt hơn trong thiết kế và triển khai của chúng, thậm chí đến mức kịch bản không tồn tại và thậm chí khái niệm rằng các trang có thể động, được tạo ra trong bộ nhớ và thay vào đó là ổ cắm là một tệp tĩnh trên đĩa được khách hàng yêu cầu và đọc và đẩy xuống ổ cắm, không tồn tại. Do đó, trang web ban đầu tập trung vào khái niệm các trang tĩnh chứa liên kết đến các trang khác, tất cả các trang tồn tại trên đĩa và điều hướng sẽ là thiết bị đầu cuối chủ yếu thực hiện các yêu cầu GET cho các trang tại URL, máy chủ sẽ có thể ánh xạ url đến một tập tin trên đĩa và gửi nó. Cũng có khái niệm rằng mạng tài liệu liên kết với nhau và tắt đi nơi khác sẽ là một sự phát triển,

Điều đó mang lại một số bối cảnh lịch sử cho các phương thức - ngày xưa URL là bit không linh hoạt và được gọi đơn giản là các trang trên đĩa nên phương thức này rất hữu ích vì nó cho phép khách hàng mô tả ý định của nó đối với tệp và máy chủ sẽ xử lý phương pháp theo một số cách khác nhau. Thực sự không có khái niệm các url là ảo hoặc được sử dụng để chuyển đổi hoặc ánh xạ trong tầm nhìn ban đầu của một siêu văn bản (và nó thực sự chỉ là Văn bản)

Tôi không có ý định cho câu trả lời này là tài liệu của hồ sơ lịch sử với ngày tháng và trích dẫn tài liệu tham khảo chính xác khi nào mọi thứ bắt đầu thay đổi - vì bạn có thể đọc Wikipedia - nhưng đủ để nói rằng qua thời gian mong muốn về web sẽ được tập hợp nhiều động lực hơn và ở mỗi đầu của kết nối máy chủ-máy khách, cơ hội tạo ra trải nghiệm đa phương tiện phong phú mà chúng tôi đang mở rộng. Các trình duyệt hỗ trợ rất nhiều thẻ để định dạng nội dung, mỗi người đua nhau thực hiện các tính năng đa phương tiện phải có và các cách mới để khiến mọi thứ trở nên hấp dẫn.

Scripting xuất hiện ở đầu máy khách, các plugin và phần mở rộng trình duyệt, tất cả đều nhằm mục đích biến trình duyệt thành một cường quốc có khả năng lớn về mọi thứ. Ở cuối máy chủ, việc tạo nội dung hoạt động dựa trên thuật toán hoặc dữ liệu cơ sở dữ liệu là một cú hích lớn và nó tiếp tục phát triển đến mức có thể có ít tệp trên đĩa nữa - chắc chắn, chúng tôi giữ một tệp hình ảnh hoặc tập lệnh dưới dạng tệp trên máy chủ web và có trình duyệt NHẬN nó, nhưng ngày càng nhiều hình ảnh trình duyệt hiển thị và các tập lệnh mà nó chạy không phải là tệp bạn có thể mở trong trình thám hiểm tệp của mình, chúng được tạo ra nội dung là quá trình biên dịch được thực hiện theo yêu cầu , SVG mô tả cách vẽ pixel thay vì mảng pixel bitmap hoặc JavaScript được phát ra từ một dạng tập lệnh cấp cao hơn như TypeScript

Khi tạo các trang nhiều megabyte hiện đại, có lẽ chỉ một phần trong số đó là nội dung cố định trên đĩa; dữ liệu cơ sở dữ liệu được định dạng và định hình thành html mà trình duyệt sẽ sử dụng và được máy chủ thực hiện để đáp ứng với nhiều thói quen lập trình khác nhau được tham chiếu theo một cách nào đó bởi url

Tôi đã đề cập trong các ý kiến ​​cho câu hỏi rằng nó hơi giống như vòng tròn đầy đủ. Quay lại khi máy tính có giá hàng trăm nghìn và đầy phòng, người ta thường cho phép nhiều người dùng sử dụng một máy tính lớn trung tâm siêu mạnh bằng hàng trăm thiết bị đầu cuối câm - một bàn phím và chuột, màn hình xanh, gửi một số văn bản, nhận được một số văn bản văn bản ra. Theo thời gian khi sức mạnh tính toán tăng lên và giá cả giảm xuống, mọi người bắt đầu kết thúc với máy tính bàn mạnh hơn máy tính lớn ban đầu và khả năng chạy các ứng dụng mạnh mẽ cục bộ để mô hình máy tính lớn trở nên lỗi thời. Mặc dù vậy, nó không bao giờ biến mất, bởi vì mọi thứ chỉ phát triển theo hướng khác và phần nào trở lại một máy chủ trung tâm cung cấp hầu hết các chức năng ứng dụng hữu ích và hàng trăm máy tính khách làm rất ít ngoại trừ vẽ trên màn hình, và gửi và nhận dữ liệu đến / từ máy chủ. Khoảng thời gian tạm thời mà máy tính của bạn đủ thông minh để chạy bản sao từ và triển vọng của chính nó đồng thời lại nhường chỗ cho văn phòng trực tuyến, trong đó trình duyệt của bạn là một thiết bị để vẽ ảnh trên màn hình và chỉnh sửa tài liệu / email bạn ' Viết lại như một thứ tồn tại trên máy chủ, được lưu ở đó, được gửi và chia sẻ với tất cả những người dùng khác vì quan niệm rằng trình duyệt chỉ là một vỏ cung cấp một cái nhìn một phần tại bất kỳ thời điểm nào của thứ này sống ở nơi khác

Từ các câu trả lời, tôi hiểu được lý do tại sao khái niệm phương pháp lại có .. Điều này dẫn đến một câu hỏi liên quan khác:

Ví dụ: trong liên kết soạn thư gmail, yêu cầu và dữ liệu PUT / POST sẽ được gửi. Làm thế nào để trình duyệt biết phương pháp sử dụng?

Nó sử dụng GET theo mặc định, theo quy ước / thông số vì đó là những gì là sự quyết định sẽ xảy ra khi bạn nhập một url và nhấn return

Trang gmail được gửi bởi máy chủ có bao gồm tên phương thức sẽ sử dụng khi gọi yêu cầu soạn gmail không?

Đây là một trong những điều quan trọng mà tôi ám chỉ trong các ý kiến ​​trên. Trong web hiện đại, nó thậm chí không còn về các trang nữa. Khi các trang là tệp trên đĩa, trình duyệt sẽ NHẬN. Sau đó, chúng trở thành các trang chủ yếu được tạo động bằng cách xiên dữ liệu vào một mẫu. Nhưng nó vẫn liên quan đến quá trình "yêu cầu một trang mới từ máy chủ, lấy một trang, hiển thị trang". Các trang hoán đổi đã thực sự trơn tru; bạn đã không thấy họ tải và thay đổi kích thước và giật bố cục của họ xung quanh để nó mượt hơn nhưng nó vẫn là trình duyệt thay thế toàn bộ một trang hoặc một phần của trang bằng một trang khác

Cách làm hiện đại là với một ứng dụng trang duy nhất; trình duyệt có một tài liệu trong bộ nhớ được hiển thị theo một cách nhất định, tập lệnh gọi đến thebservr và lấy lại một số thông tin và thao tác với tài liệu để một phần của trang thay đổi trực quan để hiển thị thông tin mới - toàn bộ mọi thứ chạy mà không có trình duyệt tải một trang mới khác; nó chỉ trở thành một giao diện người dùng nơi các phần của nó cập nhật giống như một ứng dụng khách thông thường như từ hoặc triển vọng. Các phần tử mới xuất hiện bên trên các phần tử khác và có thể được kéo xung quanh mô phỏng các cửa sổ hộp thoại, v.v ... Tất cả Đây là công cụ kịch bản trình duyệt gửi yêu cầu sử dụng bất kỳ phương thức http nào mà nhà phát triển muốn, lấy lại dữ liệu và chọc vào tài liệu mà trình duyệt đang vẽ. Bạn có thể hình dung rằng trình duyệt hiện đại là một thiết bị tuyệt vời giống như toàn bộ hệ điều hành hoặc máy tính ảo; một thiết bị lập trình có cách vẽ khá chuẩn trên màn hình, phát âm thanh, thu nhập dữ liệu của người dùng và gửi nó để xử lý. Tất cả những gì bạn phải làm để làm cho nó vẽ UI của bạn là cung cấp cho nó một số html / css để tạo UI sau đó điều chỉnh html liên tục để làm cho trình duyệt thay đổi những gì nó đang vẽ. Heck, mọi người đã quá quen với việc thay đổi thanh địa chỉ / sử dụng nó như một hướng mục đích rằng một ứng dụng trang sẽ thay đổi url theo chương trình ngay cả khi không có điều hướng (yêu cầu toàn bộ trang mới) được thực hiện Tất cả những gì bạn phải làm để làm cho nó vẽ UI của bạn là cung cấp cho nó một số html / css làm cho UI sau đó điều chỉnh html liên tục để làm cho trình duyệt thay đổi những gì nó đang vẽ. Heck, mọi người đã quá quen với việc thay đổi thanh địa chỉ / sử dụng nó như một hướng mục đích rằng một ứng dụng trang sẽ thay đổi url theo chương trình ngay cả khi không có điều hướng (yêu cầu toàn bộ trang mới) được thực hiện Tất cả những gì bạn phải làm để làm cho nó vẽ UI của bạn là cung cấp cho nó một số html / css làm cho UI sau đó điều chỉnh html liên tục để làm cho trình duyệt thay đổi những gì nó đang vẽ. Heck, mọi người đã quá quen với việc thay đổi thanh địa chỉ / sử dụng nó như một hướng mục đích rằng một ứng dụng trang sẽ thay đổi url theo chương trình ngay cả khi không có điều hướng (yêu cầu toàn bộ trang mới) được thực hiện

Khi chúng tôi gọi www.gmail.com, nó phải sử dụng phương thức GET, làm thế nào để trình duyệt biết rằng phương thức này sẽ sử dụng?

Thật. Bởi vì nó được chỉ định. Yêu cầu đầu tiên là theo lịch sử luôn luôn là - NHẬN một số html ban đầu để vẽ UI, sau đó chọc và thao tác nó mãi mãi, hoặc lấy một trang khác với tập lệnh khác chọc và thao tác và tạo giao diện người dùng phản ứng nhanh nhạy

Như một số câu trả lời cho biết, chúng tôi có thể tạo người dùng mới bằng phương pháp XÓA, sau đó điều này đặt ra câu hỏi về ý định đằng sau khái niệm phương thức trong giao thức http, bởi vì vào cuối ngày, nó hoàn toàn phụ thuộc vào máy chủ mà họ muốn ánh xạ URL tới . Tại sao khách hàng nên nói với máy chủ những phương pháp sử dụng cho URL.

Lịch sử. Di sản. Về mặt lý thuyết, chúng ta có thể loại bỏ tất cả các phương thức http vào ngày mai - chúng ta đang ở mức độ tinh vi lập trình nơi các phương thức bị lỗi thời vì các URL có thể xử lý đến mức chúng có thể là cơ chế chuyển đổi cho máy chủ biết bạn muốn lưu dữ liệu vào phần thân dưới dạng email nháp hoặc xóa bản nháp - không có tệp / email / bản nháp / lưu / 1234 trên máy chủ - máy chủ được lập trình để chọn url đó và biết phải làm gì với phần lưu dữ liệu cơ thể nó như một bản nháp email theo id 1234

Vì vậy, chắc chắn có thể loại bỏ các phương pháp, ngoại trừ trọng lượng lớn của khả năng tương thích di sản lớn lên xung quanh chúng. Tốt hơn hết là chỉ sử dụng chúng cho những gì bạn cần nhưng phần lớn bỏ qua chúng và thay vào đó sử dụng bất cứ thứ gì bạn cần để làm cho công việc của bạn hoạt động. Chúng tôi vẫn cần các phương thức được xác định bởi vì bạn phải nhớ rằng chúng có ý nghĩa gì đó đối với trình duyệt và máy chủ mà chúng tôi đã tạo ra các ứng dụng của mình. Kịch bản phía máy khách muốn sử dụng trình duyệt bên dưới để gửi dữ liệu, nó cần sử dụng một phương thức sẽ khiến trình duyệt thực hiện như yêu cầu - có thể là POST vì GET đóng gói tất cả thông tin biến của nó vào url và có giới hạn về độ dài trong rất nhiều máy chủ Máy khách muốn có phản hồi dài từ máy chủ - không sử dụng CHÍNH vì họ hoàn toàn không có cơ quan phản hồi.

HTTP có thể được coi là một trường hợp cụ thể của các nguyên tắc chung của Cuộc gọi thủ tục từ xa: bạn nói với máy chủ những gì bạn muốn với một số trường biến trong yêu cầu, máy chủ đáp ứng tương ứng. Đến bây giờ, do tính tương tác phức tạp của 'Web 2.0, các tính năng tương tự này bị loại bỏ trong mọi lĩnh vực theo yêu cầu: URL, tiêu đề, cơ thể và mỗi máy chủ ứng dụng và ứng dụng hiểu chúng theo cách riêng của chúng. Tuy nhiên, ban đầu web đơn giản hơn, sử dụng các trang tĩnh và người ta cho rằng các phương thức HTTP được cung cấp cho mức độ tương tác sẽ đủ. Đáng chú ý, HTTP có rất nhiều phương thức được sử dụng hiếm khi, nếu có, với một số trong số chúng chỉ nhìn thấy ánh sáng nhờ REST. Ví dụ: PUT và DELETE là moribund trước REST, và TRACE và PATCH vẫn chưa được nhìn thấy. Điểm đáng chú ý là mô hình RPC của HTTP đã không

REST đã làm ngược lại hoàn toàn với những gì bạn đang đề xuất, bằng cách lưu ý rằng các phương thức HTTP phục vụ các trường hợp sử dụng CRUD điển hình của hầu hết các ứng dụng nếu PUT và DELETE được đưa trở lại.

Cũng lưu ý rằng các phương thức HTTP có ngữ nghĩa được gán cho chúng, được các trình duyệt và phần mềm trung gian tôn vinh như các máy chủ proxy: các yêu cầu POST, PUT, DELETE và PATCH có thể không có tác dụng phụ, vì vậy các ứng dụng và phần mềm trung gian sẽ được cảnh báo để không kích hoạt các yêu cầu này mà không có hành động rõ ràng từ người dùng. Trong thực tế, các ứng dụng web được thiết kế kém đã sử dụng GET cho các hành động không an toàn và ví dụ: trình tải trước Google Web Accelerator gây rắc rối bằng cách xóa hàng loạt dữ liệu trên các trang web đó , vì vậy bản beta của nó đã bị đình chỉ ngay sau khi khởi chạy.

Vì vậy, để trả lời câu hỏi 'chúng ta có thể' không: chắc chắn, bạn chỉ cần đồng ý về một giao thức sẽ cho ứng dụng máy chủ biết bạn muốn thực hiện hành động nào, sau đó bạn đặt các đối số ở đâu đó trong URL / body body như mục tiêu cho hành động. Tập hợp các hành động chỉ giới hạn bởi các ứng dụng cụ thể, vì vậy bạn cần một giao thức mở rộng. Nhưng bạn sẽ cần phải cho các ứng dụng khách biết những yêu cầu nào là an toàn và có thể đưa các sắc thái khác vào tài khoản, chẳng hạn như kiểm soát bộ đệm.

Theo quan điểm cá nhân của tôi với tư cách là một nhà phát triển, nó có thể giúp việc tạo các điểm cuối API dễ dàng hơn nhiều. Chẳng hạn, nếu tôi viết một bộ điều khiển quản lý các sản phẩm trên một trang web, tôi có thể sử dụng cùng một URL để thực hiện nhiều thao tác khác nhau.

Ví dụ:

GET https://example.com/api/products/1234

Điều này sẽ lấy các chi tiết của sản phẩm 1234.

POST https://example.com/api/products/1234

Điều này sẽ tạo ra một sản phẩm có ID 1234 sử dụng dữ liệu trong thân yêu cầu.

PUT https://example.com/api/products/1234

Điều này sẽ cập nhật sản phẩm 1234 với dữ liệu trong cơ thể yêu cầu.

DELETE https://example.com/api/products/1234

Điều này sẽ xóa một sản phẩm có ID 1234.

Tôi có thể tạo các điểm cuối khác nhau cho mỗi hoạt động nhưng điều đó sẽ làm phức tạp quá trình và khiến cho các nhà phát triển khác không thể hiểu được.

Sự cần thiết của các phương thức như GET và POST trong giao thức HTTP là gì?

Dường như bạn đã quên ngày xưa khi các máy chủ HTTP ở đó chỉ để phục vụ các tệp ; không chạy tập lệnh, CGI hoặc tạo nội dung động theo kiểu đó.

Các phương thức yêu cầu là tập hợp động từ được chuẩn hóa cơ bản về những việc cần làm với các tệp đó ...

• NHẬN có nghĩa là tải xuống
• Đầu có nghĩa là có được thông tin của
• PUT có nghĩa là tải lên
• XÓA có nghĩa là loại bỏ
• POST có nghĩa là gửi dữ liệu vào
• TÙY CHỌN có nghĩa là cho tôi biết những gì tôi có thể làm

Trong ngày HTTP / 0.9, dòng yêu cầu là thứ duy nhất trong chân yêu cầu của giao thức; không có tiêu đề yêu cầu, không có tiêu đề phản hồi. Bạn chỉ cần gõ GET /somefile, nhấn Enter, máy chủ sẽ trả về nội dung phản hồi (tức là nội dung HTML) và tạm biệt cảm ơn (tức là đóng kết nối).

Nếu bạn chỉ muốn hỏi tại sao nó được thiết kế theo cách này ? Câu trả lời của tôi là bởi vì ban đầu nó được viết để xử lý loại trao đổi nội dung tồn tại trước đó , tức là phục vụ các tệp HTML tĩnh theo yêu cầu của người dùng.

Tuy nhiên, nếu bạn muốn hỏi về cách xử lý các ngữ nghĩa này trong máy chủ ứng dụng hiện đại ...

Chúng ta có thể không thực hiện giao thức HTTP chỉ bằng cách sử dụng phần thân yêu cầu và phần thân phản hồi không?

Là thực hiện các phương thức HTTP khác nhau thực sự cần thiết?

Câu trả lời của tôi là: làm bất cứ điều gì bạn muốn làm, nhưng hãy nhớ rằng bạn không nên thực hiện logic ứng dụng trong một cách mà bất chấp sự mong đợi của giao thức : mong đợi như GET không nên thay đổi dữ liệu (hoặc rất lỏng lẻo, có ít nhất idempotent kết quả ), HEAD phải có kết quả giống như GET nhưng không có phần phản hồi, PUT sẽ cung cấp nội dung của URI đích (nếu thành công).

Nếu bạn đi ngược lại mong đợi mà không xem xét cẩn thận ý nghĩa của nó , nhiều điều khó chịu sẽ xảy ra, như ...

• Khi bạn sử dụng phương thức GET để sử dụng dữ liệu, máy chủ có thể phát sinh lỗi 414 " URI quá dài " trong khuôn mặt của bạn.
• Khi bạn sử dụng phương pháp GET để sử dụng sửa đổi dữ liệu, bạn sẽ thấy rằng việc sửa đổi đôi khi không xảy ra khi người dùng đứng sau proxy lưu trữ hoặc các sửa đổi không mong muốn sẽ xảy ra khi người dùng nhớ lại URL từ dấu trang (hoặc khi trình thu thập dữ liệu web đạt đến nó) .
• Khi bạn phản hồi phương pháp CHÍNH không đúng cách, bạn sẽ thấy rằng các công cụ kiểm tra trang web tự động của bạn (ví dụ wget --spider) bảo lãnh trên trang web của bạn.
• Khi bạn đưa phương thức POST vào tải xuống nội dung, bạn sẽ thấy việc đánh dấu trang hoặc thậm chí nhập URL vào trình duyệt sẽ không hoạt động.
• Và nhiều thứ khác nữa...

" Người mới bắt đầu biết các quy tắc, nhưng các cựu chiến binh biết ngoại lệ. "

Dù sao, cuối cùng bạn có thể tìm thấy một số lý do hợp lệ để đi ngược lại một số quy tắc cho một số trường hợp sử dụng hẹp; nhưng hãy chắc chắn để làm nghiên cứu của bạn và xem xét tất cả các khả năng. Nếu không, bạn sẽ kết thúc khả năng tương tác và làm hỏng "trải nghiệm người dùng".

Không có gì đảm bảo rằng người dùng luôn sử dụng các sản phẩm khách hàng / tác nhân người dùng chính thống mà bạn đã thử nghiệm. Họ có thể sử dụng một nhãn hiệu địa phương phù hợp với nhu cầu của họ (bao gồm cả tôi), một nhãn hiệu tùy chỉnh mà họ đặt hàng từ cửa hàng đặc biệt bên cạnh hoặc một nhãn hiệu cổ điển mà họ đã đào ra khỏi kho. Ngay cả với tất cả những điều này, các trang web của bạn vẫn được mong đợi sẽ cung cấp một dịch vụ hợp lý. Đó là một lý do tại sao chúng ta có các tiêu chuẩn.

Bất cẩn phá vỡ tiêu chuẩn cũng có nghĩa là bạn đang áp dụng phân biệt đối xử đối với người dùng của mình.

Đó là sự thật trong lý thuyết chúng ta có thể sử dụng có được ở khắp mọi nơi và nó sẽ sắp xếp công việc. Một số phần mềm thậm chí sử dụng GET với yêu cầu cơ thể (Tôi đang nhìn vào bạn elaticsearch / kibana). Điều này tất nhiên là một điều khủng khiếp để.

Lý do quan trọng nhất là vì các phương pháp khác nhau có ngữ nghĩa khác nhau. Một số là an toàn, một số là idempotent. Một số là cả hai. Xem cái nào

Điều này rất quan trọng, ví dụ như khi tương tác với các ứng dụng khác. Điểm cuối GET không được cho là có tác dụng phụ. Điều này rất quan trọng khi google đang bò về phía bạn. PUT được coi là không có nghĩa là khách hàng có thể tự do thử lại trong trường hợp thất bại. Đây không phải là trường hợp của POST mà tại sao các trình duyệt phải có hộp xác nhận xấu nếu bạn nhấn f5 trong yêu cầu bài đăng.

Xem những gì có thể xảy ra nếu bạn sử dụng GET nơi bạn nên sử dụng POST

Bạn cũng có thể nghĩ về GET, POST, v.v. như quá tải của cùng một chức năng, hoặc thậm chí là getters và setters.

GET_MyVar() sẽ không lấy thông số đầu vào (còn gọi là Cơ quan yêu cầu), nhưng trả lại một cái gì đó.

POST_MyVar(string blah)làm một cái gì đó với đầu vào (một lần nữa, cơ thể yêu cầu) và có thể trả lại một cái gì đó. (Ít nhất cũng cần trả về mã phản hồi, để chúng tôi biết chức năng đã chạy !!)

DELETE_MyVar() Cũng có thể không mất bất cứ điều gì và dự kiến ​​sẽ xóa một cái gì đó.

Có, chúng tôi có thể thực hiện tất cả với:
MyVar(string Action, string? blah)

Bằng cách này, chúng tôi có thể chấp nhận chỉ một cuộc gọi và sau đó chọn phải làm gì dựa trên một số tham số khác.

Nhưng một trong những tiện ích của phương pháp này là nó cho phép trình duyệt và máy chủ tối ưu hóa cách thức hoạt động của những thứ này. Ví dụ, có thể máy chủ sẽ muốn chặn tất cả các yêu cầu ở đâu Action==DELETE. Có thể các trình duyệt muốn lưu trữ những thứ mà Action==GET.nếu không, trong mọi chức năng chúng ta sẽ phải viếtif (Action==Delete) {return AngryFace}

Không có yêu cầu để thực hiện mọi thứ chính xác theo giao thức, nhưng về cơ bản giao thức là một bộ quy tắc mà tất cả chúng ta quyết định tuân theo. Bằng cách đó, tôi có thể dễ dàng đoán được trang web của bạn sẽ làm gì, ngay cả khi tôi chưa thấy máy chủ!

Các phương thức HTTP phục vụ các mục đích khác nhau. Nói chung, GETlà để tải xuống và POSTlà để tải lên.

Cách duy nhất để thực hiện một phần của giao thức HTTP chỉ sử dụng phần thân yêu cầu và phần thân phản hồi sẽ là triển khai POST. GETkhông có cơ thể yêu cầu. Nó chỉ có yêu cầu với tiêu đề, nhưng không có cơ thể. Nó chỉ là một yêu cầu cho một tài liệu để tải về. POSTcó cả thân yêu cầu (tệp tải lên) và thân phản hồi (tài liệu hiển thị kết quả).

Vì vậy, bạn có thể chỉ cần thực hiện POSTvà được thực hiện? Không phải nếu bạn muốn trang web của bạn có thể sử dụng được trong các trình duyệt tiêu chuẩn. Loại yêu cầu mặc định mà trình duyệt gửi là GET. POSTyêu cầu thường chỉ được gửi khi biểu mẫu trong các trang web được gửi hoặc cho các cuộc gọi AJAX. Chỉ khi máy chủ cụ thể này chỉ được sử dụng cho các cuộc gọi AJAX và không cho các trang hiển thị cho người dùng, bạn mới có thể thoát khỏi POST.

Trình duyệt đôi khi cũng gửi HEADyêu cầu để kiểm tra xem một tài liệu đã thay đổi kể từ lần cuối họ tải xuống, vì vậy ít nhất cũng nên thực hiện điều đó.

Trong mọi trường hợp, không có lý do chính đáng để triển khai máy chủ web cho trang web của bạn từ đầu. Giao thức HTTP rất phức tạp. Ngoài các phương pháp khác nhau, bạn cũng sẽ phải thực hiện các yêu cầu đường ống và phân đoạn. Việc xây dựng ứng dụng web của bạn trên một máy chủ web như Apache, Nginx hoặc IIS xử lý giao thức HTTP cho bạn dễ dàng hơn nhiều. Bạn đề cập đến Servlets, vì vậy có lẽ bạn nên sử dụng máy chủ web Tomcat hoặc JBoss chạy Servlets.

Bạn đã đúng, chúng ta có thể làm điều đó, GET, POST, PUT, v.v. chỉ là những quy ước lịch sử nếu tôi có cách HTTP sẽ được thay thế chỉ bằng phương thức POST và không có gì khác, mặc dù tôi phải thừa nhận loại bỏ GET sẽ là một công việc to lớn, Điều đó không thể được thực hiện, con ngựa đã bắt được con ngựa đó

Giao thức được đề xuất của bạn sẽ được bảo mật ít hơn đáng kể chống lại tin tặc.

Có một lý do tại sao các trang web đã chuyển sang lưu trữ thông tin về các biến và như vậy trong URL, và lý do đó rất đơn giản: nó cung cấp cho kẻ tấn công một cách rất đơn giản để tấn công hệ thống của bạn. Bằng cách quan sát thông tin URL văn bản gốc, họ có thể xác định thời trang mà dữ liệu được gửi đến máy chủ web của bạn được xây dựng; sau đó họ có thể sử dụng thông tin này để thực hiện một cuộc tấn công vào máy chủ của bạn bằng cách sử dụng URL được xây dựng đặc biệt cho phép họ tiêm mã độc hoặc dữ liệu vào máy chủ của bạn.