API REST: tiêu đề HTTP tùy chỉnh so với thông số URL

96

Khi nào bạn sử dụng tiêu đề HTTP tùy chỉnh trong phần yêu cầu của API REST?

Thí dụ:

Bạn có bao giờ sử dụng

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

thay vì

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

http rest

— Vasile Cotovanu
nguồn

123

URL cho biết chính tài nguyên đó. Một "khách hàng" là một nguồn lực có thể bị tác động, vì vậy nên là một phần của địa chỉ cơ sở: /orders/view/client/23.

Tham số chỉ có vậy, để tham số hóa quyền truy cập vào tài nguyên. Điều này đặc biệt phát huy tác bằng bài đăng và tìm kiếm: /orders/find?q=blahblah&sort=foo. Có một ranh giới mong manh giữa các thông số và phụ nguồn: /orders/view/client/23/active versus /orders/view/client/23?show=active. Tôi đề xuất kiểu tài nguyên phụ và tham số dự trữ cho các tìm kiếm.

Vì mỗi điểm cuối đại diện cho một Chuyển trạng thái (để ghi nhớ), tiêu đề tùy chỉnh chỉ nên được sử dụng cho những thứ không liên quan đến tên của tài nguyên (url), trạng thái của tài nguyên (nội dung) hoặc các tham số trực tiếp ảnh hưởng đến tài nguyên (tham số). Điều đó để lại siêu dữ liệu thực sự về yêu cầu tiêu đề tùy chỉnh.

HTTP có rất nhiều lựa chọn tiêu đề bao gồm hầu hết mọi thứ bạn cần. Nơi tôi đã thấy các tiêu đề tùy chỉnh xuất hiện là trong một hệ thống yêu cầu hệ thống hoạt động thay mặt người dùng. Hệ thống proxy sẽ xác nhận người dùng và thêm " X-User: userid" vào tiêu đề và sử dụng thông tin đăng nhập hệ thống để truy cập điểm cuối. Hệ thống nhận xác thực rằng thông tin xác thực hệ thống được ủy quyền để hành động thay mặt cho người dùng, sau đó xác nhận rằng người dùng được ủy quyền để thực hiện hành động.

— Nialscorva
nguồn

Cảm ơn vì một câu trả lời toàn diện! Bạn sẽ vẫn sử dụng X-User cho một API di động trong đó nguy cơ có proxy xấu (làm mất tiêu đề) vẫn cao chứ?

— Vasile Cotovanu

1

Không, việc sử dụng X-User mà tôi đã đề cập là trong hệ thống với các kết nối hệ thống mà hệ thống đang hoạt động thay mặt cho bên thứ ba. Ví dụ: Người dùng U nói chuyện với Máy chủ A. Máy chủ A trình bày thông tin đăng nhập cho Máy chủ B với tiêu đề Người dùng X để nói "Sử dụng thông tin đăng nhập của tôi để kiểm tra xem tôi có được ủy quyền thực hiện hành động này thay mặt Người dùng U." Điều này xuất hiện trong Kiến trúc hướng dịch vụ và thông thường bạn đang sử dụng HTTPS. Nền tảng di động hầu như luôn phải do Người dùng tự hành động và sử dụng thông tin đăng nhập của người đầu tiên thích hợp cho giao dịch.

— Nialscorva

7

Đoạn thứ ba là một trong những câu trả lời nhiều thông tin nhất mà tôi đã đọc trên SO ;-)

— Alistair77,

1

@Nialscorva Lời giải thích tuyệt vời! Điều gì sẽ xảy ra nếu tôi muốn người dùng tương tác với API của tôi thông qua một vùng chứa được ủy quyền (như ứng dụng dành cho thiết bị di động của tôi)? Những gì tôi đang làm bây giờ là ứng dụng dành cho thiết bị di động của tôi không được phép tự thực hiện bất kỳ hành động nào và cũng không phải người dùng cuối .. cả hai thông tin xác thực phải có nếu người dùng sẵn sàng thực hiện một hành động.

— bolbol

6

Tiêu đề tùy chỉnh có những ưu điểm sau:

Có thể được đọc dễ dàng bằng các công cụ / tập lệnh mạng (xác thực, thông tin meta, ...)
Giữ các url không bị dính các thứ bảo mật (an toàn hơn, không nằm trong bộ đệm trình duyệt / proxy)
Giữ url sạch hơn: cho phép lưu trữ tài nguyên tốt hơn

— Christophe Roussy
nguồn

chúng cũng có thể bị xóa / lọc âm thầm bởi proxy

— fusi

@fusi điểm tốt ... đây là chủ đề về nó: stackoverflow.com/questions/20820572/…

— Christophe Roussy

5

Tôi sẽ chỉ sử dụng tiêu đề tùy chỉnh khi không có cách nào khác để chuyển thông tin theo tiêu chuẩn hoặc quy ước. Darren102 đang giải thích cách điển hình để vượt qua giá trị đó. Api của bạn sẽ thân thiện hơn nhiều bằng cách sử dụng câu mẫu điển hình bằng cách sử dụng tiêu đề tùy chỉnh.

— kiện
nguồn

Toàn tâm toàn ý đồng ý ... không bao giờ phát minh lại bánh xe nếu có một cách tiêu chuẩn để hoàn thành nhiệm vụ.

— Alessandro Santini

5

Khi nào bạn sử dụng ... tiêu đề HTTP trong phần yêu cầu của API REST?

Xác thực: GUID, xác thực cơ bản, mã thông báo tùy chỉnh, v.v. ví dụ: Xác thực cơ bản bằng mã thông báo hướng dẫn cho REST api thay vì tên người dùng / mật khẩu

Nếu bạn tham gia vào việc chuyển mã thông báo hoặc thông tin giống như xác thực khác giữa các miền được bao phủ bởi PCI-DSS hoặc các quy tắc bảo mật khác, bạn cũng có thể phải chôn vùi các tham số vì một số quy định yêu cầu rõ ràng các yếu tố xác thực tránh các URL có thể được phát lại một cách đáng kể (từ lịch sử trình duyệt, nhật ký proxy, v.v.).

— người dùng3038458
nguồn

1

Không có tiêu chuẩn cho REST tuy nhiên cách được chấp nhận sẽ là

GET /orders/view/23

Không sử dụng các tiêu đề tùy chỉnh và do đó chế độ xem sau 23 giả định là id do đó bạn sẽ có một hàm nhận id và do đó chỉ tạo ra thông tin đó.

— darren102
nguồn

1

Tôi sẽ không sử dụng tiêu đề tùy chỉnh vì bạn không biết liệu có proxy nào sẽ chuyển những tiêu đề đó hay không. Dựa trên URL là cách để đi.

NHẬN / đơn đặt hàng / xem / khách hàng / 23

— Antony Scott
nguồn

1

Tôi cũng sẽ không khuyến nghị các tiêu đề tùy chỉnh, nhưng proxy bị hỏng không phải là lý do. Proxy bị hỏng cần được sửa.

— Julian Reschke

1

Chắc chắn là OK:

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

Cũng được:

GET /orders/view/23 or

Tôi nghĩ điều này cũng sẽ ổn:

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23

— paulsm4
nguồn

Phản hồi REST-ful POST phải là HTTP 303 với tiêu đề Vị trí được đặt thành một cái gì đó như "/ order / view / 23".

— Rich Remer

0

Bạn có thể sử dụng các tiêu đề tùy chỉnh để bao gồm thêm thông tin về một yêu cầu đã được xử lý một phần vì cho rằng Phong bì không phải là một phương pháp hay. Các tiêu đề được bảo mật .

— Anwar Husain
nguồn