Hoạt động không hợp lệ của mã Mã trạng thái trong mã HATEOAS REST


8

Trong một liên kết API HATEOAS được trả về đại diện cho các chuyển trạng thái có thể. Một khách hàng tuân thủ chỉ nên truy xuất và theo các liên kết đó, nhưng nếu một khách hàng không tuân thủ đang xây dựng các URI thay vì theo các liên kết được cung cấp thì mã trạng thái / phản hồi thích hợp nhất sẽ trả về là gì?

  • 400 sẽ hoạt động, cùng với một số thông tin trong cơ quan phản hồi - đây là những gì chúng tôi hiện đang làm
  • 403 Tôi đoán là sẽ sai, vì nó ngụ ý rằng yêu cầu không bao giờ có thể hoạt động - nhưng có khả năng liên kết có thể có sẵn trong tương lai
  • 404 nghe có vẻ hợp lý - tại thời điểm này tài nguyên không tồn tại

Mọi người nghĩ gì? Tôi biết rằng các yêu cầu có điều kiện có thể xử lý các yêu cầu dựa trên các phản hồi cũ (kết quả là ví dụ 412), nhưng đây là một tình huống hơi khác.

Cập nhật:

OK, tôi thấy rằng phản hồi chính xác cho các loại hoạt động không hợp lệ này sẽ là 404. Làm thế nào về cú pháp của yêu cầu là chính xác, nó sẽ chuyển đến một tài nguyên hợp lệ nhưng bằng cách nào đó nó vi phạm quy tắc kinh doanh. Dưới đây là một vài ví dụ giả định:

  1. Giả sử khách hàng có thể cung cấp hai số phải nằm trong phạm vi 20% của nhau, nhưng nếu không thì có thể là bất kỳ số nào.
  2. Giả sử khách hàng có thể cung cấp một số thông qua một số tính toán kết quả cho thấy số ban đầu được cung cấp là không chính xác.

Là 400 là phản ứng chính xác cho những điều này?


Câu trả lời:


5

Nếu có khả năng các liên kết sẽ tồn tại trong tương lai, cả 400 Yêu cầu xấu403 Bị cấm sẽ không chính xác: cả hai phần có liên quan trong RFC 2616 đều có hướng dẫn rằng khách hàng KHÔNG NÊN lặp lại yêu cầu. Sự khác biệt giữa hai điều này là, trong trường hợp 400 Yêu cầu Không hợp lệ , máy chủ không hiểu khách hàng đang cố gắng làm gì, trong khi với 403 Cấm máy chủ đã hiểu yêu cầu, nhưng từ chối thực hiện yêu cầu đó (bao giờ).

Nếu bạn muốn cho khách hàng biết rằng yêu cầu đã được hiểu, nhưng bạn sẽ không xử lý nó tại thời điểm yêu cầu (nhưng không đưa ra yêu cầu nào về việc xử lý nó trong tương lai), 404 Not Found sẽ là phản hồi phù hợp nhất để gửi.

Nếu bạn muốn cho khách hàng biết rằng yêu cầu đã được hiểu, nhưng yêu cầu không tuân theo các quy tắc hoặc nguyên tắc được xác định trước (như ví dụ của bạn về việc khách hàng không cung cấp hai số trong phạm vi 20% cho nhau), bạn muốn sử dụng 409 Xung đột , trong đó được dự định để cho khách hàng biết rằng yêu cầu cần phải được sửa chữa để được xử lý đúng.

Tuy nhiên, bạn nên tách biệt sự không tuân thủ đức tin với sự không tuân thủ đức tin xấu. Nếu bạn đang cố gắng bảo vệ ứng dụng của mình khỏi các yêu cầu của một diễn viên xấu, họ gần như chắc chắn sẽ không quan tâm đến mã phản hồi nào bạn gửi: họ sẽ tiếp tục xây dựng URL cho đến khi họ đạt được thứ gì đó họ thích.


OK, tôi nghĩ rằng điều đó đến trung tâm của câu hỏi. Tôi đã mở rộng trên đó một chút để bao quát phạm vi hoạt động không hợp lệ rộng hơn - có lẽ đối với 400 điều này là phản hồi chính xác?
FinnNk

@FinnNk Không, 400 Yêu cầu Không hợp lệ chỉ khi máy chủ không thể hiểu khách hàng đang cố gắng làm gì. Nếu nó hiểu yêu cầu nhưng nội dung của yêu cầu không hợp lệ, bạn muốn phản hồi với 409 Xung đột.

2

Các mã này tuân theo tiêu chuẩn được đặt bởi rfc HTTP .

Theo phần Định nghĩa mã trạng thái :

  • 400 yêu cầu xấu

Máy chủ không thể hiểu được yêu cầu do cú pháp không đúng. Khách hàng KHÔNG NÊN lặp lại yêu cầu mà không sửa đổi.

  • 403 Cấm

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó. Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại. Nếu phương thức yêu cầu không phải là CHÍNH và máy chủ muốn công khai lý do tại sao yêu cầu chưa được thực hiện, thì NÊN mô tả lý do từ chối trong thực thể. Nếu máy chủ không muốn cung cấp thông tin này cho khách hàng, mã trạng thái 404 (Không tìm thấy) có thể được sử dụng thay thế.

  • 404 Không tìm thấy

Máy chủ không tìm thấy bất cứ thứ gì khớp với URI yêu cầu. Không có dấu hiệu nào được đưa ra cho dù điều kiện là tạm thời hay vĩnh viễn. Mã trạng thái 410 (Đã qua) NÊN được sử dụng nếu máy chủ biết, thông qua một số cơ chế có thể định cấu hình bên trong, rằng tài nguyên cũ không có sẵn vĩnh viễn và không có địa chỉ chuyển tiếp. Mã trạng thái này thường được sử dụng khi máy chủ không muốn tiết lộ chính xác lý do tại sao yêu cầu bị từ chối hoặc khi không có phản hồi nào khác được áp dụng.

Trong trường hợp của bạn, nếu URI được xây dựng không dẫn đến bất cứ nơi nào tôi nghĩ rằng nó sẽ phù hợp để trả về 404 .

nếu URI hợp lệ nhưng dữ liệu được truyền (như tài liệu json) bị hỏng , thì bạn nên trả về 400 .

CHỈNH SỬA :

Trả lời bình luận của OP: Tôi nghĩ hệ thống sẽ trả về 400 khi cú pháp và ý nghĩa của dữ liệu bị phá vỡ.


Do bị hỏng, trong ngữ cảnh của API REST, bạn chỉ có nghĩa là cú pháp hay nó cũng bao gồm cả ý nghĩa của dữ liệu? Xem câu hỏi mở rộng để biết thêm chi tiết.
FinnNk

Cả hai trường hợp nên trả lại 400, theo ý kiến ​​khiêm tốn của tôi.
karlphillip

Tôi đã chấp nhận câu trả lời của bạn, nhưng bạn có thể chuyển nhận xét của mình vào phần thân câu trả lời không? Chúc mừng.
FinnNk

Khi đọc lại HTTPc HTTPc, phản hồi tiếp theo của Mark rất có ý nghĩa, vì vậy tôi đã chuyển câu trả lời được chấp nhận. Tôi phải nói rằng đó là sự kết hợp của cả hai câu trả lời của bạn đã giúp tôi hiểu sâu hơn ở đây.
FinnNk
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.