Tôi có nên cho phép các tham số chưa biết?

Tôi đang thiết kế API RESTful và đối mặt với vấn đề tiêu đề, được trình bày lại cho rõ ràng:

Tôi có nên thất bại nhanh nếu khách hàng gửi tham số không được nhận dạng không? Ví dụ,

http://example.com/api/foo?bar=true&paula=bean

Ở trên, barlà một tham số hợp lệ nhưng paulakhông được API chỉ định. Tôi có nên

Cảnh báo khách hàng về lỗi
Thất bại nhanh
Bỏ mặc nó

Nếu tôi cảnh báo khách hàng, tôi chỉ có thể đưa ra cảnh báo cho tham số đầu tiên, vì họ có thể gửi số lượng gần như vô hạn của họ và máy chủ có lẽ có nhiều việc phải làm. Tương tự, khi thất bại, nó sẽ chỉ xác định tham số không hợp lệ đầu tiên là sự cố.

Tôi thích thất bại hơn là đưa ra cảnh báo để buộc lập trình viên phải hành động, vì nếu không họ có thể bỏ qua vấn đề và tiếp tục lãng phí tài nguyên, hoặc tự mình kết thúc việc nuôi trồng hàng hóa. Không làm gì thậm chí còn tồi tệ hơn trong khía cạnh đó.

Lập luận của tôi có ý nghĩa? Có một thực hành được chấp nhận về những điều như vậy?

rest api-design

— rath
nguồn

Dựa trên một thử nghiệm nhỏ, tất cả các trang web mà tôi đã kiểm tra chỉ cần bỏ qua các tham số chưa biết mà tôi đã cung cấp chúng.

— Bart van Ingen Schenau

@BartvanIngenSchenau Tương tự ở đây. Đó là tốt cho các trang web, nhưng tôi không nghĩ rằng đó là ok cho một API thực tế

— Rath

Một mối quan tâm là khả năng tương thích về phía trước. Nếu các đối số không xác định bị bỏ qua, có thể sử dụng chúng trong các phiên bản trong tương lai theo cách mà khách hàng có thể lập trình với API mới và vẫn có hành vi hợp lý trên các máy chủ cũ.

— walpen

@walpen Đó là một điểm thú vị. Sử dụng các URL được phiên bản, api/v1v.v. sẽ đảm bảo điều đó, nhưng nó vẫn không cho phép cập nhật gia tăng. 1

— Rath

Ở đó bạn có thể tìm thấy một số ưu và nhược điểm từ quan điểm sống thực: Thông số nghiêm ngặt và API của bạn .

— Remek Ambroziak

Câu trả lời:

Theo tôi, bạn nên trả lại trạng thái Yêu cầu không hợp lệ để khách hàng biết rằng những gì nó đang cố gắng không hợp lệ. Ý kiến của tôi về điều này bị ảnh hưởng bởi khái niệm rằng API RESTful có thể khám phá được . Nếu bạn đang cung cấp đủ thông tin trước, thì khách hàng sẽ không bao giờ cố gắng đưa ra yêu cầu không hợp lệ để bắt đầu. Nếu đúng như vậy, thì có lỗi gì đó trong mã máy khách và không nhanh sẽ báo lỗi thứ hai cho lỗi này. Tất nhiên, đó là một cách tiếp cận rất thuần túy và có thể không được khuyến nghị nếu API của bạn không thể khám phá được.

Một cách tiếp cận thực tế hơn có thể là bỏ qua các thông số không hợp lệ, nhưng dù bạn đi bằng cách nào, hãy chắc chắn ghi lại hành vi tốt.

— Vịt cao su
nguồn

Là một phần mở rộng: nếu khách hàng gửi một số tham số không xác định / chỉ đọc / không dùng nữa, điều đó có nghĩa là khách hàng mong đợi một số hành vi sẽ không được thực hiện. Và do đó, thật nguy hiểm khi thực hiện bất kỳ hành động. Vì vậy, tôi đồng ý, hoàn toàn Yêu cầu xấu

— Stepan Stepanov

Cảm ơn @StepanStepanov, nhưng có triết lý "Hãy cho phép những gì bạn chấp nhận, rõ ràng về những gì bạn gửi đi" dựa trên phần lớn kiến trúc của web. Với ý nghĩ đó, tôi có thể dễ dàng viết một câu trả lời đối lập trực tiếp với câu tôi đã viết.

— RubberDuck

Tôi đã hiểu điều này)) Và trang về luật của Postel cũng nói rằng "mã nhận đầu vào nên chấp nhận đầu vào không tuân thủ miễn là ý nghĩa rõ ràng". Tôi nghĩ, nếu khách hàng gửi cho chúng tôi một số tham số chưa biết, ý nghĩa của nó không thể rõ ràng. Nếu khách hàng gửi cho chúng tôi một tham số không dùng nữa thì rõ ràng, nó sẽ không hoạt động như trước và như khách hàng mong đợi. Nếu khách hàng gửi cho chúng tôi một tham số chỉ đọc thì rõ ràng, nó sẽ không được viết như khách hàng muốn.

— Stepan Stepanov

Nếu bạn thực hiện API công khai (hoặc api sẽ được sử dụng bởi nhóm khác), tôi sẽ khuyên bạn nên trả về lỗi như @RubberDuck đề xuất.

Nếu api của bạn sẽ chỉ được tiêu thụ trong nhóm của bạn (hoặc chỉ một mình), có thể dễ dàng bỏ qua các trường bổ sung (ví dụ: yêu cầu ít mã hơn và dễ làm hơn).

— Konstantin Petrukhnov
nguồn