Xác định thao tác VPN trước khi so sánh API

Một trang sản phẩm nói rằng nó có API, và cuộc họp tích hợp dừng lại ở câu hỏi thứ hai. Thao tác nào, trên đối tượng nào, ai gọi, và điều gì được coi là thành công? Trả lời bốn điều đó trước khi so sánh sản phẩm thường loại bỏ một nửa ứng viên. Nó cũng biến phần so sánh còn lại thành thứ mà một bài kiểm tra có thể giải quyết.

Thay «có API» bằng một thao tác

API là phương tiện truyền tải, không phải năng lực. Một điểm cuối REST, một ổ cắm cục bộ và một lớp bao dòng lệnh đều có thể được gọi là API, và chúng không cung cấp các thao tác tương đương.

Viết thao tác thành một câu trước khi xem tài liệu.

Bắt đầu một kết nối cục bộ là hành động phía máy khách với người dùng ở phía trước. Phát hành hồ sơ thiết bị là hành động cung cấp với danh mục thiết bị ở phía sau. Vô hiệu hóa quyền truy cập của người dùng là hành động quản trị với dấu vết kiểm toán. Ba việc này thường nằm ở các thành phần khác nhau, do các nhóm khác nhau sở hữu, với thẩm quyền khác nhau.

Bốn trường khiến hợp đồng có thể kiểm thử

Điền bốn trường cho mỗi thao tác: đối tượng, hành động, người gọi và điều kiện thành công. Một hợp đồng thiếu trường là một điều ước.

Bảng là toàn bộ bảng tính:

Điều kiện thành công là trường mà người ta bỏ qua, và chính nó quyết định tích hợp có hoạt động hay không. Một cài đặt đã lưu không phải là đường hầm đang hoạt động, và một tài khoản bị vô hiệu hóa không phải là phiên đã kết thúc.

Nếu hai thao tác cần những người gọi khác nhau, đó là hai tích hợp. Gộp chúng vào một tài khoản dịch vụ thường có nghĩa là cấp nhiều thẩm quyền hơn mức mỗi bên cần.

Khớp giao diện với lớp mà nó thực sự thuộc về

Giao diện quản lý của cộng đồng OpenVPN nói chuyện với daemon qua TCP hoặc ổ cắm Unix. Các lệnh của nó bao gồm quan sát trạng thái và tín hiệu tới daemon.

Điều đó khiến nó là kênh điều khiển daemon, không phải API đăng ký được lưu trữ hay dịch vụ đăng ký người dùng. Đọc tài liệu của nó cẩn thận giúp bạn không xây dựng trên một lớp không sở hữu đối tượng.

Tài liệu đó cũng nói rằng giao thức không có mã hóa riêng. Ai tiếp cận được ổ cắm thì có thể điều khiển daemon, vì vậy hãy coi nó là điều khiển nhạy cảm, không phải luồng số liệu. Hãy gắn nó với loopback hoặc một ổ cắm Unix, và đặt sau một bố trí hạn chế nếu người gọi từ xa cần. Việc phơi nó ra internet cho tiện sẽ biến một kênh điều khiển thành sự cố.

Chỉ định hành vi sau khi gọi

Chấp nhận không giống như hoàn tất. Daemon có thể trả về trước khi đường hầm lên, vì vậy hãy chờ sự kiện hoàn tất hoặc thất bại được ghi trong tài liệu và gắn nó với yêu cầu bạn đã gửi.

Quyết định người gọi làm gì nếu phản hồi bị mất. Lặp lại mù quáng một lần tạo hoặc kết nối lại không giống với kiểm tra xem yêu cầu đầu tiên đã có hiệu lực chưa.

Gỡ bỏ quyền truy cập là ít nhất ba hành động khác nhau: chặn đăng nhập trong tương lai, kết thúc một phiên đang hoạt động và thu hồi thông tin đăng nhập. Hãy yêu cầu những gì chính sách thực sự đòi hỏi, và nói trong hợp đồng cái nào là cái nào. Đừng dán nhãn một lần cập nhật tài khoản thành công là thu hồi hoàn toàn mà không có bằng chứng. Sự khác biệt này quan trọng trong sự cố, khi đồng hồ đang chạy.

Kiểm tra hợp đồng bằng một phi công

Một phi công nhỏ đã được phê duyệt nên bao gồm thành công, từ chối, gián đoạn và thử lại, sau đó là thao tác ứng dụng cần được cho phép hoặc từ chối.

Đối với giao diện cấp daemon, hai lệnh thực hành quan sát và một tín hiệu:

echo state | nc -w 2 127.0.0.1 7505
echo signal SIGTERM | nc -w 2 127.0.0.1 7505

Chỉ cấp thẩm quyền mà thao tác đòi hỏi. Giữ bí mật ngoài nhật ký thường lệ, và ghi đủ chi tiết riêng tư để nói mục tiêu nào bị ảnh hưởng và nó kết thúc thế nào.

Ghi lại đường phục hồi cho trường hợp chính API điều khiển bị ngừng. Chọn giao diện sở hữu đối tượng và vòng đời của nó; những tuyên bố tự động hóa trên trang sản phẩm không phải là thứ thay thế.