2013-04-08 29 views
5

Lời nói đầu:Tôi có nên sử dụng tiêu đề Content-Location theo cách này không?

Sau khi đọc rất nhiều về HTTP và REST, bạn đã dành một vài giờ để xây dựng một chương trình thương lượng nội dung xảo quyệt. Để API web của bạn có thể phân phối XML, JSON và HTML từ một URL duy nhất. Bởi vì, bạn biết đấy, một tài nguyên chỉ nên có một URL và các biểu diễn khác nhau nên được yêu cầu bằng cách sử dụng các tiêu đề Accept. Bạn bắt đầu tự hỏi tại sao phải mất 20 năm để thực hiện điều đó.

Và đó là khi thực tế slaps you in the face.

Vì vậy, để giúp các trình duyệt (và bản thân bạn đang cố gắng gỡ lỗi) với việc ép buộc dịch vụ của bạn để phục vụ loại nội dung mong muốn, bạn làm những gì mọi người truyền giáo REST tự tôn trọng sẽ khinh thường bạn: .

Sự tổn thương vĩnh viễn trong địa ngục mặc dù, việc sử dụng sau đây là Content-Location + .ext có thể chấp nhận được không?

Giả sử chúng tôi có người dùng tại /users/:loginname ví dụ /users/bob. Đây sẽ là điểm cuối API cho bất kỳ thứ gì có khả năng đặt tiêu đề Accept thích hợp. Nhưng đối với bất kỳ có thể Content-Type (hoặc ít nhất một số), chúng tôi cho phép một phương pháp truy cập thay thế và đó là một URL có hậu tố filetype. Ví dụ: /users/bob.html để trình bày HTML. Giả sử (và đó là một giả định lớn để thực hiện) tên đăng nhập sẽ không bao giờ chứa một dấu chấm/dấu chấm.

Yêu cầu:

GET /users/bob.json HTTP/1.1 
Host: example.com 

đáp ứng:

HTTP/1.1 200 OK 
Content-Type: application/json 
Content-Length: 14 
Content-Location: /users/bob 

{"foo": "bar"} 

Điều này sẽ cho phép tôi để mã hóa thay thế cách để truy cập (trong trường hợp này) thông tin người dùng. Ví dụ: liên kết tới trang người dùng có thể là <a href="https://stackoverflow.com/users/bob.html">Bob</a>. Liên kết tới vCard (để thêm người dùng vào Address-Book/Outlook/bất kỳ thứ gì) sẽ là <a href="https://stackoverflow.com/users/bob.vcf">Bob</a>.

Có bất kỳ cạm bẫy nào tôi đã bỏ lỡ không? Điều gì sẽ là ưu/nhược điểm của điều này?

Chỉnh sửa: This xuất hiện muộn một chút để tôi chú ý. Và mặc dù nó chạm vào chủ đề và thực sự hữu ích, tôi nghĩ rằng nó không phải là chính xác những gì tôi đang tìm kiếm ...

Trả lời

0

Theo RFC 2616:

The Content-Location entity-header field MAY be used to supply 
the resource location for the entity enclosed in the message 
when that entity is accessible from a location separate from 
the requested resource's URI. 

The Content-Location value is not a replacement for the original 
requested URI; it is only a statement of the location of the resource 
corresponding to this particular entity at the time of the request. 

nói chung, có, bạn có thể sử dụng tiêu đề Content-Location để xác định nguồn gốc. Bất lợi chính của việc sử dụng hậu tố tiện ích mở rộng là bạn đang tạo một URL khác, ví dụ:/users/bob, /users/bob.vfc, /users/bob.html là ba tài nguyên khác nhau.

1

Theo như tôi có thể biết, bạn sử dụng Nội dung vị trí chính xác theo cách sai; nó sẽ trỏ đến URI cụ thể hơn.

Các vấn đề liên quan