HTTP GET với thân yêu cầu

Tôi đang phát triển một dịch vụ web RESTful mới cho ứng dụng của chúng tôi.

Khi thực hiện GET trên các thực thể nhất định, khách hàng có thể yêu cầu nội dung của thực thể. Nếu họ muốn thêm một số tham số (ví dụ: sắp xếp danh sách), họ có thể thêm các tham số này trong chuỗi truy vấn.

Ngoài ra, tôi muốn mọi người có thể chỉ định các tham số này trong thân yêu cầu. HTTP / 1.1 dường như không rõ ràng cấm điều này. Điều này sẽ cho phép họ chỉ định thêm thông tin, có thể giúp chỉ định các yêu cầu XML phức tạp dễ dàng hơn.

Những câu hỏi của tôi:

• Đây có phải là một ý tưởng tốt hoàn toàn?
• Các máy khách HTTP có gặp vấn đề với việc sử dụng các thân yêu cầu trong yêu cầu GET không?

http://tools.ietf.org/html/rfc2616

Nhận xét của Roy Fielding về việc bao gồm một cơ thể với yêu cầu GET .

Đúng. Nói cách khác, bất kỳ thông báo yêu cầu HTTP nào cũng được phép chứa phần thân thông điệp và do đó phải phân tích các thông điệp với ý nghĩ đó. Tuy nhiên, ngữ nghĩa máy chủ cho GET, bị hạn chế sao cho một phần thân, nếu có, không có ý nghĩa ngữ nghĩa đối với yêu cầu. Các yêu cầu về phân tích cú pháp tách biệt với các yêu cầu về ngữ nghĩa phương thức.

Vì vậy, vâng, bạn có thể gửi một cơ thể với GET, và không, nó không bao giờ hữu ích để làm như vậy.

Đây là một phần của thiết kế lớp của HTTP / 1.1 sẽ trở nên rõ ràng một lần nữa khi thông số kỹ thuật được phân vùng (công việc đang diễn ra).

.... Roy

Có, bạn có thể gửi một yêu cầu với GET nhưng nó không có nghĩa gì cả. Nếu bạn cho ý nghĩa của nó bằng cách phân tích cú pháp trên máy chủ và thay đổi phản hồi của bạn dựa trên nội dung của nó , thì bạn đang bỏ qua đề xuất này trong thông số HTTP / 1.1, phần 4.3 :

[...] Nếu phương thức yêu cầu không bao gồm ngữ nghĩa được xác định cho phần thân thực thể, thì phần thân thông báo NÊN bị bỏ qua khi xử lý yêu cầu.

Và mô tả về phương thức GET trong thông số HTTP / 1.1, phần 9.3 :

Phương thức GET có nghĩa là lấy bất kỳ thông tin nào ([...]) được xác định bởi URI yêu cầu.

trong đó tuyên bố rằng phần thân yêu cầu không phải là một phần của việc xác định tài nguyên trong yêu cầu GET, chỉ là URI yêu cầu.

Cập nhật RFC2616 được tham chiếu là "thông số HTTP / 1.1" hiện đã lỗi thời. Trong năm 2014, nó đã được thay thế bởi RFC 7230-7237. Trích dẫn "phần thân thông điệp NÊN bỏ qua khi xử lý yêu cầu" đã bị xóa. Bây giờ chỉ là "Đóng khung thông báo yêu cầu độc lập với ngữ nghĩa của phương thức, ngay cả khi phương thức không xác định bất kỳ việc sử dụng nào cho nội dung thư" Trích dẫn thứ 2 "Phương thức GET có nghĩa là lấy bất kỳ thông tin nào ... được xác định bởi URI yêu cầu" đã bị xóa. - Từ một bình luận

Mặc dù bạn có thể làm điều đó, trong trường hợp không được loại trừ rõ ràng bởi đặc tả HTTP, tôi khuyên bạn nên tránh nó đơn giản vì mọi người không mong đợi mọi thứ hoạt động theo cách đó. Có nhiều giai đoạn trong chuỗi yêu cầu HTTP và trong khi chúng "hầu hết" tuân thủ thông số HTTP, điều duy nhất bạn yên tâm là chúng sẽ hoạt động như các trình duyệt web thường sử dụng. (Tôi đang nghĩ về những thứ như proxy trong suốt, máy gia tốc, bộ công cụ A / V, v.v.)

Đây là tinh thần đằng sau Nguyên tắc mạnh mẽ đại khái là "tự do trong những gì bạn chấp nhận và bảo thủ trong những gì bạn gửi", bạn không muốn đẩy ranh giới của một đặc tả mà không có lý do chính đáng.

Tuy nhiên, nếu bạn có một lý do chính đáng, hãy đi cho nó.

Bạn có thể sẽ gặp phải vấn đề nếu bạn cố gắng tận dụng bộ nhớ đệm. Các proxy sẽ không nhìn vào phần GET để xem các tham số có ảnh hưởng đến phản hồi không.

Cả giao diện điều khiển restclient và REST đều không hỗ trợ điều này nhưng curl thì không.

Đặc tả HTTP nói trong phần 4.3

Phần thân thông báo KHÔNG được đưa vào yêu cầu nếu đặc tả của phương thức yêu cầu (phần 5.1.1) không cho phép gửi phần thân thực thể trong các yêu cầu.

Mục 5.1.1 chuyển hướng chúng tôi đến mục 9.x cho các phương pháp khác nhau. Không ai trong số họ rõ ràng cấm đưa vào nội dung thư. Tuy nhiên...

Mục 5.2 nói

Tài nguyên chính xác được xác định bởi một yêu cầu Internet được xác định bằng cách kiểm tra cả URI Yêu cầu và trường tiêu đề Máy chủ.

và Phần 9.3 nói

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.

Cùng nhau đề xuất rằng khi xử lý yêu cầu GET, máy chủ không bắt buộc phải kiểm tra bất cứ thứ gì khác ngoài trường tiêu đề Request-URI và Host.

Tóm lại, thông số HTTP không ngăn bạn gửi nội dung thư bằng GET nhưng có sự mơ hồ đủ để nó không làm tôi ngạc nhiên nếu nó không được tất cả các máy chủ hỗ trợ.

Elaticsearch chấp nhận các yêu cầu GET với một cơ thể. Dường như đây là cách ưa thích: Hướng dẫn Elaticsearch

Một số thư viện máy khách (như trình điều khiển Ruby) có thể ghi nhật ký lệnh khóc vào thiết bị xuất chuẩn trong chế độ phát triển và nó đang sử dụng cú pháp này rộng rãi.

Những gì bạn đang cố gắng đạt được đã được thực hiện trong một thời gian dài với một phương pháp phổ biến hơn nhiều và một phương pháp không dựa vào việc sử dụng tải trọng với GET.

Bạn có thể chỉ cần xây dựng kiểu tìm kiếm cụ thể của mình hoặc nếu bạn muốn RESTful hơn, hãy sử dụng một cái gì đó như OpenSearch và POST yêu cầu tới URI mà máy chủ hướng dẫn, nói / tìm kiếm. Sau đó, máy chủ có thể tạo kết quả tìm kiếm hoặc xây dựng URI cuối cùng và chuyển hướng bằng cách sử dụng 303.

Điều này có lợi thế là theo phương pháp PRG truyền thống, giúp bộ đệm trung gian lưu trữ kết quả, v.v.

Điều đó nói rằng, URI được mã hóa bằng mọi cách không phải là ASCII, và ứng dụng / x-www-form-urlencoding và multiart / form-data cũng vậy. Tôi khuyên bạn nên sử dụng điều này thay vì tạo một định dạng json tùy chỉnh khác nếu ý định của bạn là hỗ trợ các kịch bản ReSTful.

Bạn có thể gửi một GET với một cơ thể hoặc gửi POST và từ bỏ tính tôn giáo RESTish (điều đó không tệ lắm, 5 năm trước chỉ có một thành viên của đức tin đó - những bình luận của anh ấy được liên kết ở trên).

Không phải là quyết định tuyệt vời, nhưng việc gửi một cơ quan GET có thể ngăn chặn sự cố cho một số khách hàng - và một số máy chủ.

Làm một POST có thể có những trở ngại với một số khung RESTish.

Julian Reschke đã đề xuất ở trên bằng cách sử dụng tiêu đề HTTP không chuẩn như "TÌM KIẾM" có thể là một giải pháp tao nhã, ngoại trừ việc nó thậm chí còn ít được hỗ trợ hơn.

Có thể là hiệu quả nhất để liệt kê các khách hàng có thể và không thể làm từng điều ở trên.

Các khách hàng không thể gửi GET với cơ thể (mà tôi biết):

• Trình điều khiển XmlHTTPRequest

Các khách hàng có thể gửi một GET với cơ thể:

• hầu hết các trình duyệt

Máy chủ và thư viện có thể truy xuất nội dung từ GET:

• Apache
• PHP

Máy chủ (và proxy) tước cơ thể khỏi GET:

• ?

Tôi đặt câu hỏi này cho IETF HTTP WG. Nhận xét từ Roy Fielding (tác giả của tài liệu http / 1.1 năm 1998) là

"... một việc thực hiện sẽ bị phá vỡ để làm bất cứ điều gì khác ngoài việc phân tích và loại bỏ cơ thể đó nếu nhận được"

Các trạng thái RFC 7213 (HTTPbis):

"Một tải trọng trong một thông báo yêu cầu GET không có ngữ nghĩa được xác định;"

Bây giờ có vẻ rõ ràng rằng ý định là ý nghĩa ngữ nghĩa đối với các cơ quan yêu cầu GET bị cấm, điều đó có nghĩa là cơ thể yêu cầu không thể được sử dụng để ảnh hưởng đến kết quả.

Có những proxy ngoài đó chắc chắn sẽ phá vỡ yêu cầu của bạn theo nhiều cách khác nhau nếu bạn bao gồm một cơ thể trên GET.

Vì vậy, tóm lại, đừng làm điều đó.

Máy chủ nào sẽ bỏ qua nó? - fijiaaron ngày 30 tháng 8 năm 12 lúc 21:27

Google chẳng hạn đang làm tồi tệ hơn là bỏ qua nó, nó sẽ coi đó là một lỗi !

Hãy thử nó với một netcat đơn giản:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(nội dung 1234 được theo sau bởi CR-LF, do đó tổng cộng là 6 byte)

và bạn sẽ nhận được:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

Bạn cũng nhận được 400 Yêu cầu xấu từ Bing, Apple, v.v ... được phục vụ bởi AkamaiGhost.

Vì vậy, tôi sẽ không khuyên sử dụng các yêu cầu GET với một thực thể cơ thể.

Từ RFC 2616, phần 4.3 , "Nội dung thư":

Một máy chủ NÊN đọc và chuyển tiếp nội dung thư theo bất kỳ yêu cầu nào; nếu phương thức yêu cầu không bao gồm ngữ nghĩa được xác định cho một thực thể, thì phần thân thông báo NÊN bị bỏ qua khi xử lý yêu cầu.

Nghĩa là, các máy chủ phải luôn luôn đọc bất kỳ nội dung yêu cầu nào được cung cấp từ mạng (kiểm tra Độ dài nội dung hoặc đọc phần thân, v.v.). Ngoài ra, proxy nên chuyển tiếp bất kỳ cơ quan yêu cầu như vậy họ nhận được. Sau đó, nếu RFC định nghĩa ngữ nghĩa cho phần thân cho phương thức đã cho, thì máy chủ thực sự có thể sử dụng phần thân yêu cầu để tạo phản hồi. Tuy nhiên, nếu RFC không xác định ngữ nghĩa cho phần thân, thì máy chủ nên bỏ qua nó.

Điều này phù hợp với trích dẫn từ Fielding ở trên.

Mục 9.3 , "NHẬN", mô tả ngữ nghĩa của phương thức GET và không đề cập đến các cơ quan yêu cầu. Do đó, một máy chủ nên bỏ qua mọi yêu cầu mà nó nhận được trong yêu cầu GET.

Theo XMLHttpRequest, nó không hợp lệ. Từ tiêu chuẩn :

4.5.6 send()Phương pháp

client . send([body = null])

Bắt đầu yêu cầu. Đối số tùy chọn cung cấp phần thân yêu cầu. Đối số được bỏ qua nếu phương thức yêu cầu là GEThoặc HEAD.

Ném một InvalidStateErrorngoại lệ nếu một trong hai trạng thái không được mở hoặc send()cờ được đặt.

Các phương pháp phải chạy các bước sau:send(body)

1. Nếu trạng thái không được mở , ném một InvalidStateErrorngoại lệ.
2. Nếu send()cờ được đặt, ném một InvalidStateErrorngoại lệ.
3. Nếu phương thức yêu cầu là GEThoặc HEAD, đặt thân thành null.
4. Nếu cơ thể là null, đi đến bước tiếp theo.

Mặc dù, tôi không nghĩ vậy bởi vì yêu cầu GET có thể cần nội dung lớn.

Vì vậy, nếu bạn dựa vào XMLHttpRequest của trình duyệt, có thể nó sẽ không hoạt động.

Nếu bạn thực sự muốn gửi phần thân JSON / XML có thể lưu vào bộ nhớ cache cho ứng dụng web, nơi hợp lý duy nhất để đặt dữ liệu của bạn là chuỗi truy vấn được mã hóa bằng RFC4648: Mã hóa cơ sở 64 với URL và Tên tệp Bảng chữ cái an toàn . Tất nhiên, bạn có thể chỉ cần urlencode JSON và đặt vào giá trị của URL param, nhưng Base64 cho kết quả nhỏ hơn. Hãy nhớ rằng có các hạn chế kích thước URL, xem Độ dài tối đa của URL trong các trình duyệt khác nhau là bao nhiêu? .

Bạn có thể nghĩ rằng =ký tự đệm của Base64 có thể không tốt cho giá trị param của URL, tuy nhiên có vẻ như không - xem cuộc thảo luận này: http://mail.python.org/pipermail/python-bugs-list 2007-F/2/037195.html . Tuy nhiên, bạn không nên đặt dữ liệu được mã hóa mà không có tên param vì chuỗi được mã hóa với phần đệm sẽ được hiểu là khóa param có giá trị trống. Tôi sẽ sử dụng một cái gì đó như ?_b64=<encodeddata>.

Tôi sẽ không khuyên điều này, nó đi ngược lại các thông lệ tiêu chuẩn và không mang lại nhiều lợi ích như vậy. Bạn muốn giữ cơ thể cho nội dung, không phải tùy chọn.

Điều gì về các tiêu đề mã hóa base64 không phù hợp? "SOMETHINGAPP-PARAM: sdfSD45fdg45 / aS"

Hạn chế chiều dài hm. Bạn có thể làm cho việc xử lý POST của bạn phân biệt giữa các ý nghĩa không? Nếu bạn muốn các tham số đơn giản như sắp xếp, tôi không thấy lý do tại sao điều này sẽ là một vấn đề. Tôi đoán đó là sự chắc chắn mà bạn lo lắng.

Tôi rất buồn vì REST là giao thức không hỗ trợ OOP và Getphương thức là bằng chứng. Là một giải pháp, bạn có thể tuần tự hóa DTO thành JSON và sau đó tạo chuỗi truy vấn. Về phía máy chủ, bạn sẽ có thể giải tuần tự chuỗi truy vấn thành DTO.

Hãy xem:

• Thiết kế dựa trên thông báo trong ServiceStack
• Xây dựng các dịch vụ web dựa trên tin nhắn RESTful với WCF

Cách tiếp cận dựa trên thông báo có thể giúp bạn giải quyết giới hạn phương thức. Bạn sẽ có thể gửi bất kỳ DTO nào như với cơ quan yêu cầu

Khung dịch vụ web của Nelibur cung cấp chức năng mà bạn có thể sử dụng

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Ví dụ, nó hoạt động với Curl, Apache và PHP.

Tệp PHP:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Lệnh Console:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

Đầu ra:

GET
{"the": "body"}

IMHO bạn chỉ có thể gửi JSONmã hóa (ví dụ. encodeURIComponent) URLTheo cách này, bạn không vi phạm HTTPthông số kỹ thuật và đưa bạn JSONđến máy chủ.

Bạn có một danh sách các tùy chọn tốt hơn nhiều so với việc sử dụng phần thân yêu cầu với GET.

Giả sử bạn có danh mục và mục cho từng danh mục. Cả hai được xác định bởi một id ("catid" / "itemid" vì lợi ích của ví dụ này). Bạn muốn sắp xếp theo một "tham số" khác trong một "thứ tự" cụ thể. Bạn muốn truyền tham số cho "sortby" và "order":

Bạn có thể:

1. Sử dụng chuỗi truy vấn, ví dụ: example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. Sử dụng mod_rewrite (hoặc tương tự) cho các đường dẫn: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. Sử dụng các tiêu đề HTTP riêng lẻ mà bạn chuyển qua với yêu cầu
4. Sử dụng một phương pháp khác, ví dụ POST, để lấy tài nguyên.

Tất cả đều có nhược điểm của chúng, nhưng tốt hơn nhiều so với sử dụng GET với cơ thể.

Ngay cả khi một công cụ phổ biến sử dụng điều này, như được trích dẫn thường xuyên trên trang này, tôi nghĩ nó vẫn là một ý tưởng khá tồi, quá kỳ lạ, mặc dù không bị cấm bởi thông số kỹ thuật.

Nhiều cơ sở hạ tầng trung gian có thể từ chối các yêu cầu như vậy.

Bằng ví dụ, quên về việc sử dụng một số các CDN sẵn ở phía trước của trang web của bạn, như thế này một :

Nếu GETyêu cầu người xem bao gồm một phần thân, CloudFront trả về mã trạng thái HTTP 403 (Bị cấm) cho người xem.

Và có, thư viện khách của bạn cũng có thể không hỗ trợ phát ra các yêu cầu như vậy, như đã báo cáo trong bình luận này .

Tôi đang sử dụng RestTemplate của khung công tác Spring trong chương trình máy khách của mình và, ở phía máy chủ, tôi đã xác định một yêu cầu GET với phần thân Json. Mục đích chính của tôi giống như của bạn: khi yêu cầu có nhiều tham số, việc đặt chúng vào cơ thể có vẻ gọn gàng hơn so với việc đưa chúng vào chuỗi URI kéo dài. Đúng?

Nhưng, thật đáng buồn, nó không hoạt động! Phía máy chủ đã ném ngoại lệ sau:

org.springframework.http.converter.HttpMessageNotReadableException: Yêu cầu cơ thể yêu cầu bị thiếu ...

Nhưng tôi khá chắc chắn rằng phần thân thông điệp được cung cấp chính xác bởi mã khách hàng của tôi, vậy có gì sai?

Tôi bắt nguồn từ phương thức RestTemplate.exchange () và tìm thấy như sau:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

Xin lưu ý rằng trong phương thức execI Internalal (), đối số đầu vào 'bufferedOutput' chứa phần thân thông điệp được cung cấp bởi mã của tôi. Tôi đã nhìn thấy nó thông qua trình gỡ lỗi.

Tuy nhiên, do readyConnection (), getDoOutput () trong execI Internalal () luôn trả về false, do đó, làm cho bufferedOutput hoàn toàn bị bỏ qua! Nó không được sao chép vào luồng đầu ra.

Do đó, chương trình máy chủ của tôi không nhận được thông báo nào và đã ném ngoại lệ đó.

Đây là một ví dụ về RestTemplate của khung công tác Spring. Vấn đề là, ngay cả khi phần thân thông điệp không còn bị cấm bởi thông số HTTP, một số thư viện hoặc khung máy chủ hoặc máy khách vẫn có thể tuân thủ thông số cũ và từ chối phần thân thông báo từ yêu cầu GET.