Các phương thức API RESTful; ĐẦU & TÙY CHỌN

Tôi đang viết một mô-đun API RESTful cho một ứng dụng bằng PHP và tôi hơi hỗn hợp về các động từ HEADvà OPTIONS.

• OPTIONS  Được sử dụng để truy xuất các động từ HTTP có sẵn cho một tài nguyên nhất định?
• HEAD Được sử dụng để xác định xem một tài nguyên nhất định có sẵn không?

Nếu ai đó có thể làm rõ * những động từ này, điều đó sẽ được đánh giá cao.

_{* Việc làm rõ liên quan đến các kiến ​​trúc API RESTful tái sử dụng các động từ HTTP. Kể từ đó, tôi nhận ra rằng cả hai HEADvà khôngOPTIONS nên được tái sử dụng, thay vào đó hoạt động có thể dự đoán được như bất kỳ ứng dụng HTTP nào. Ồ, chúng ta phát triển như thế nào trong 2 năm.}

Theo: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2 TÙY CHỌN

Phương thức OPTIONS thể hiện một yêu cầu cung cấp thông tin về các tùy chọn giao tiếp có sẵn trên chuỗi yêu cầu / phản hồi được xác định bởi URI Yêu cầu. Phương pháp này cho phép máy khách xác định các tùy chọn và / hoặc yêu cầu liên quan đến tài nguyên hoặc các khả năng của máy chủ mà không ám chỉ hành động tài nguyên hoặc bắt đầu truy xuất tài nguyên.

Các phản hồi cho phương pháp này không thể lưu vào bộ nhớ cache.

Nếu yêu cầu TÙY CHỌN bao gồm nội dung thực thể (như được chỉ ra bởi sự hiện diện của Độ dài nội dung hoặc Mã hóa truyền), thì loại phương tiện PHẢI được chỉ ra bởi trường Loại nội dung. Mặc dù thông số kỹ thuật này không xác định bất kỳ mục đích sử dụng nào cho phần thân như vậy, nhưng các phần mở rộng trong tương lai cho HTTP có thể sử dụng phần nội dung OPTIONS để thực hiện các truy vấn chi tiết hơn trên máy chủ. Máy chủ không hỗ trợ phần mở rộng như vậy CÓ THỂ loại bỏ phần thân yêu cầu.

Nếu URI Yêu cầu là dấu hoa thị ("*"), thì yêu cầu TÙY CHỌN nhằm áp dụng cho máy chủ nói chung chứ không phải cho một tài nguyên cụ thể. Vì các tùy chọn giao tiếp của máy chủ thường phụ thuộc vào tài nguyên, yêu cầu "*" chỉ hữu ích như một loại phương thức "ping" hoặc "no-op"; nó không làm gì khác ngoài việc cho phép máy khách kiểm tra khả năng của máy chủ. Ví dụ: điều này có thể được sử dụng để kiểm tra proxy về sự tuân thủ HTTP / 1.1 (hoặc thiếu nó).

Nếu URI Yêu cầu không phải là dấu hoa thị, thì yêu cầu TÙY CHỌN chỉ áp dụng cho các tùy chọn có sẵn khi giao tiếp với tài nguyên đó.

Phản hồi 200 NÊN bao gồm bất kỳ trường tiêu đề nào cho biết các tính năng tùy chọn được máy chủ triển khai và áp dụng cho tài nguyên đó (ví dụ: Cho phép), có thể bao gồm các phần mở rộng không được xác định bởi đặc tả này. Cơ quan phản hồi, nếu có, cũng NÊN bao gồm thông tin về các tùy chọn giao tiếp. Định dạng cho phần thân như vậy không được xác định bởi thông số kỹ thuật này, nhưng có thể được xác định bởi các phần mở rộng trong tương lai cho HTTP. Thương lượng nội dung CÓ THỂ được sử dụng để chọn định dạng phản hồi thích hợp. Nếu không có nội dung phản hồi nào được bao gồm, thì phản hồi PHẢI bao gồm trường Độ dài nội dung với giá trị trường là "0".

Trường tiêu đề yêu cầu Max-Forwards CÓ THỂ được sử dụng để nhắm mục tiêu một proxy cụ thể trong chuỗi yêu cầu. Khi một proxy nhận được một yêu cầu OPTIONS trên một cổng tuyệt đối được phép chuyển tiếp yêu cầu, proxy PHẢI kiểm tra trường Chuyển tiếp Tối đa. Nếu giá trị trường Max-Forwards bằng 0 ("0"), proxy KHÔNG PHẢI chuyển tiếp thông báo; thay vào đó, proxy NÊN phản hồi bằng các tùy chọn giao tiếp của riêng nó. Nếu giá trị trường Max-Forwards là một số nguyên lớn hơn 0, proxy PHẢI giảm giá trị trường khi nó chuyển tiếp yêu cầu. Nếu không có trường Chuyển tiếp Tối đa nào trong yêu cầu, thì yêu cầu được chuyển tiếp KHÔNG PHẢI bao gồm trường Chuyển tiếp Tối đa.

9.4 ĐẦU

Phương thức HEAD giống với GET ngoại trừ việc máy chủ KHÔNG PHẢI trả lại nội dung thư trong phản hồi. Thông tin siêu dữ liệu chứa trong các tiêu đề HTTP phản hồi yêu cầu HEAD NÊN giống với thông tin được gửi để phản hồi yêu cầu GET. Phương pháp này có thể được sử dụng để thu thập thông tin về thực thể được ám chỉ bởi yêu cầu mà không cần chuyển chính nội dung thực thể. Phương pháp này thường được sử dụng để kiểm tra các liên kết siêu văn bản về tính hợp lệ, khả năng truy cập và sửa đổi gần đây.

Phản hồi cho một yêu cầu HEAD CÓ THỂ được lưu vào bộ nhớ cache theo nghĩa là thông tin có trong phản hồi CÓ THỂ được sử dụng để cập nhật một thực thể đã lưu trong bộ nhớ cache trước đó từ tài nguyên đó. Nếu các giá trị trường mới chỉ ra rằng thực thể được lưu trong bộ nhớ cache khác với thực thể hiện tại (như được chỉ ra bởi sự thay đổi về Nội dung-Độ dài, Nội dung-MD5, ETag hoặc Sửa đổi lần cuối), thì bộ nhớ cache PHẢI coi mục nhập trong bộ nhớ cache là cũ.

OPTIONSmethod trả về thông tin về API (method / content type)

HEADphương thức trả về thông tin về tài nguyên (phiên bản / độ dài / loại)

Phản hồi của máy chủ

TÙY CHỌN

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0

CÁI ĐẦU

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270

• OPTIONS Xác định phương thức HTTP nào mà tài nguyên hỗ trợ, ví dụ như chúng ta có thể XÓA nó hoặc cập nhật nó qua PUT không?
• HEADKiểm tra xem tài nguyên đã thay đổi chưa. Điều này hữu ích khi duy trì phiên bản được lưu trong bộ nhớ cache của tài nguyên
• HEAD Truy xuất siêu dữ liệu về tài nguyên, ví dụ: loại phương tiện hoặc kích thước của nó, trước khi thực hiện truy xuất có thể tốn kém
• HEAD, OPTIONSKiểm tra xem tài nguyên có tồn tại và có thể truy cập được hay không. Ví dụ: xác thực các liên kết do người dùng gửi trong một ứng dụng

Đây là bài viết hay và ngắn gọn về cách HEAD và OPTIONS phù hợp với kiến ​​trúc RESTful.

OPTIONS cho bạn biết những điều như "Phương pháp nào được phép cho tài nguyên này".

HEAD nhận tiêu đề HTTP mà bạn sẽ nhận được nếu bạn thực hiện yêu cầu GET nhưng không có phần nội dung. Điều này cho phép khách hàng xác định thông tin bộ nhớ đệm, loại nội dung nào sẽ được trả về, mã trạng thái nào sẽ được trả lại. Tính khả dụng chỉ là một phần nhỏ của nó.