@NewtonProtocol $NEWT #Newt

KHI "OPTIONAL" KHÔNG HÔN LUÔN LÀ TÙY CHỌN: MỘT CHI TIẾT NHỎ TRONG QUY TRÌNH TẠO NHIỆM VỤ CỦA NEWTON

Tôi thấy mình mất nhiều thời gian hơn dự kiến để suy nghĩ về việc "tùy chọn" thực sự có nghĩa là gì trong một API. Về mặt giấy tờ, nó có vẻ khá rõ ràng. Trong thực tế, nó lại thường phụ thuộc vào ngữ cảnh.

Đó là ấn tượng tôi có được khi xem xét luồng tạo tác vụ của Newton. Lược đồ cơ sở coi intent_signature là tùy chọn, nhưng một số chính sách và luồng dựa trên danh tính vẫn phụ thuộc vào trường này. Nếu những luồng đó kỳ vọng một chữ ký EIP-712 hợp lệ, việc để trống trường có thể khiến yêu cầu thất bại ngay trước khi chính sách được đánh giá.

Ban đầu, tôi nghĩ đó là một mâu thuẫn. Càng tìm hiểu, tôi càng cảm thấy đó là hệ quả của việc hỗ trợ nhiều mô hình ủy quyền khác nhau thông qua cùng một endpoint. Sự linh hoạt giúp giao diện dễ tái sử dụng hơn, nhưng đồng thời cũng chuyển nhiều trách nhiệm hơn sang phần tích hợp.

Điều tôi vẫn đang nghĩ đến không hẳn nằm ở chính lược đồ. Mà là việc liệu các nhà phát triển có luôn biết nhất quán rằng yêu cầu nào đến từ endpoint và yêu cầu nào đến từ chính sách mà họ đang gọi hay không. Sự phân biệt đó có thể cuối cùng sẽ quan trọng không kém gì chính logic của chính sách.
#newt #NewtonProtocol
$LAB $VANRY

API Newton: Các trường "tùy chọn" có nên thực sự là tùy chọn không?