Cảnh báo trong API REST không phải là lỗi nghiêm trọng

9

Tôi có API REST mà đối với một số tùy chọn như XÓA, POST hoặc PUT Tôi có một số quy tắc xác thực có thể trả về lỗi.

Bây giờ tôi cần một loại lỗi mới như lỗi không nghiêm trọng, rằng nó sẽ thất bại theo cách thông thường, nhưng nên thực hiện hành động nếu có cờ "cảnh báo thay thế" gửi. Một người dùng như vậy có thể được hỏi: "Bạn có chắc chắn muốn thay đổi trạng thái này, bạn chưa kết thúc"

Câu hỏi : có cách thực hành tốt nhất cho các loại lỗi này không?

Câu hỏi phụ :

Có bất kỳ ngữ nghĩa HTTP cho hành vi như vậy mà tôi có thể sử dụng?
Tôi vẫn theo ý tưởng REST (đối với tôi có vẻ như tôi làm) - Tôi giữ nó không trạng thái

rest api

— người dùng237329
nguồn

Làm thế nào để bạn quyết định có hiển thị cảnh báo như vậy cho người dùng? Bạn gọi một điểm cuối API để kiểm tra trạng thái ứng dụng và sau đó trình bày cho người dùng một hộp thoại như vậy, chặn UI cho đến khi người dùng phản hồi. Sau đó, bạn thực hiện cuộc gọi thực tế. Bạn cũng nên lập mô hình này với API REST: thêm điểm cuối để kiểm tra xem nó có lưu để thực hiện một số tác vụ nhất định không. Bằng cách này, bất kỳ người dùng API nào cũng có thể thực hiện kiểm tra "trước chuyến bay" và thậm chí ủy quyền quyết định cho người dùng. Cách tiếp cận mã trạng thái HTTP của bạn giống như rm /file"cảnh báo" tệp chỉ đọc trong khi vẫn xóa nó.

— thử bắt cuối cùng vào

Điều này xảy ra khi doanh nghiệp bị chồng chéo với mã trạng thái giao thức. Dù sao đi nữa. Bạn đã thử sử dụng mã trạng thái HTTP của riêng mình chưa? Nếu Twitter có thể, bạn cũng vậy. Hãy nói ví dụ 6xx? Dù sao cho đến nay tôi biết, bạn có thể thêm tin nhắn vào nội dung phản hồi ngay cả khi đó là 4xx (phạm vi sẽ được phân bổ trong trường hợp của bạn).

— Laiv

Cuối cùng tôi đã sử dụng 409 CONFLICTđể phản ứng cảnh báo. Bằng cách này, khách hàng được hướng dẫn rằng nó có thể buộc cuộc gọi có cùng điểm cuối và thân máy với tham số exttra "force = 1"

— user237329

4

Không có mã kết quả cảnh báo nào trong http, bạn trả về thành công (200) hoặc lỗi (400, 500). Điều duy nhất tôi biết có thể tương tự với những gì bạn muốn là một cái gì đó giống như mã 401 'không được phép' - đó là một lỗi hoàn toàn, nhưng khiến hầu hết các khách hàng tự động thử lại kết nối với thông tin đăng nhập.

Đối với API REST, bạn cần cho máy chủ biết trạng thái của yêu cầu và cách xử lý kết quả - bạn không thể gửi PUT và gặp lỗi nếu máy khách chưa kết thúc hoặc thành công nếu có - máy chủ cần biết điều này thông tin để gửi lại mã kết quả đúng.

Vì vậy, bạn có thể gửi cờ 'loại bỏ cảnh báo' với yêu cầu của mình, nếu không được đặt, máy chủ sẽ trả về mã lỗi 409 (hoặc tương tự) và nếu được đặt, thay vào đó hãy trả lại mã 200. Người dùng không thể được hỏi 'bạn có muốn thay đổi trạng thái này không' sau khi thay đổi trạng thái được gửi.

Bạn có thể yêu cầu máy chủ hỏi xem người dùng có thể thay đổi trạng thái của khóa học hay không và làm theo yêu cầu thích hợp sau đó.

— gbjbaanb
nguồn

Tôi không có cách nào để nói rằng đó là điều đúng đắn phải làm, nhưng mã 3xx có thể được xem là một loại thông báo hoặc mã cảnh báo nơi khách hàng có thể quyết định tiến hành. Điều đó nói rằng, tôi muốn thực hiện một hành động hoặc tôi không thực hiện và có thể tôi sẽ trả lời phản hồi với thông tin bổ sung trong phần trả về hoặc trong các tiêu đề.

— Archimedix

0

Nếu bạn muốn cho phép người dùng ghi đè xử lý lỗi thông thường của bạn, bạn có thể xem xét trả lại trạng thái 200 THÀNH CÔNG với thông tin bổ sung trong các tiêu đề HTTP mở rộng. Ví dụ: bạn có thể quay lại

X-APP-STATUS: 422 Unprocessable entity
X-APP-SOURCE: Invalid ID 'fo0'

Điều này sẽ cung cấp cho mã phía khách hàng của bạn thông tin cần thiết để cảnh báo người dùng hoặc tự mình thực hiện các hành động khắc phục.

— TMN
nguồn

2

Tôi không bao giờ thích câu trả lời rằng "Tôi đã thất bại thành công" :-)

— gbjbaanb