Ngay khi bạn phát hành ứng dụng, nó có thể được thiết kế ngược lại. Điều này có nghĩa là bạn không thể làm gì để được bảo vệ 100% nếu cùng một ứng dụng (cùng nhị phân, cùng cài đặt) được phân phối cho tất cả người dùng của bạn.
Nếu bạn có thể tùy chỉnh ứng dụng cho mọi người dùng, thì bạn có thể không cấm một số ứng dụng khác sử dụng API của mình, nhưng ít nhất giới hạn ứng dụng này theo số lượng yêu cầu mà API có thể thực hiện đối với API.
Hãy tưởng tượng lược đồ sau:
- Máy khách kết nối và gửi định danh duy nhất của nó (một định danh theo người dùng).
- Máy chủ trả lời bằng cách gửi một thách thức được mã hóa bằng khóa chung. Khóa công khai này được liên kết với mã định danh duy nhất được gửi trước đó.
- Khách hàng giải quyết thách thức bằng cách giải mã dữ liệu bằng khóa riêng và gửi bí mật được giải mã trở lại máy chủ.
- Máy chủ xác minh rằng bí mật được gửi tương ứng với bí mật được tạo ban đầu.
Nhà phát triển sẽ hack ứng dụng của bạn và lấy thành công khóa riêng sẽ có thể sử dụng API của bạn từ ứng dụng của mình, nhưng anh ta sẽ được nhận dạng là chính mình cho máy chủ của bạn.
Nếu cùng một người dùng có thể thực hiện 10 000 yêu cầu cho API của bạn mỗi ngày và trung bình, một người dùng tích cực thực hiện 2 000 yêu cầu mỗi ngày, điều đó có nghĩa là nhà phát triển này có thể tự sử dụng ứng dụng của mình và có thể cung cấp cho bạn bè của mình, nhưng anh ta sẽ không thể nói, bán nó cho hàng ngàn người, chỉ vì nó sẽ hoạt động chỉ trong vài phút vào buổi sáng.
Trong khi điều này giúp, nó cũng không phải là bằng chứng 100%. Điều gì sẽ xảy ra nếu tin tặc tìm cách trích xuất khóa riêng từ ứng dụng của bạn khi ứng dụng của chính nó được cài đặt trên thiết bị?
Lưu ý phụ không trả lời câu hỏi của bạn, nhưng vẫn có thể hữu ích: đừng nghĩ về API như một công cụ cho sản phẩm chính của bạn (ứng dụng di động). Hãy nghĩ về nó như một sản phẩm hạng nhất , một sản phẩm có thể được trả tiền. Mô hình tương tự được sử dụng trong nhiều năm bởi Amazon và Google, nó bắt đầu được Microsoft tích cực sử dụng với Azure, v.v.
Ngay khi bạn coi API không phải là một công cụ thứ cấp giảm xuống làm nô lệ cho các ứng dụng di động mới sáng bóng của bạn, mà là sản phẩm thực tế, ngang với bất kỳ ứng dụng nào mà người dùng thực sự nhìn thấy, bạn bắt đầu suy nghĩ ít hơn về cách bảo vệ API chống lại việc sử dụng bởi các ứng dụng khác và nhiều thông tin hơn về việc kiếm tiền từ chính API . API này có thể được sử dụng bởi các ứng dụng của bạn là khách hàng của nó hoặc bất kỳ ứng dụng nào khác được phát triển tự do bởi bất kỳ ai. Điều này có một số lợi ích:
Việc tạo một API để các ứng dụng của bạn chỉ được sử dụng là khó khăn và tốn kém. Thời gian và tiền bạc này có thể được sử dụng cho một cái gì đó hữu ích hơn.
Mở API của bạn ra công chúng có thể mang lại lợi ích lớn cho cả bạn và thế giới. Hãy tưởng tượng bạn là một kiến trúc sư tuyệt vời và một nhà phát triển tuyệt vời, vì vậy bạn đã tạo ra một API tuyệt vời đáng kinh ngạc, nhưng các kỹ năng thiết kế hình ảnh của bạn rất tệ và bạn thực sự không hiểu gì về thiết kế tương tác, v.v. Nếu bạn ẩn API của mình, chỉ điều mọi người sẽ biết là bạn đã tạo ra một ứng dụng di động không thể sử dụng được và xấu xí. Nếu API của bạn là công khai, các nhà phát triển khác sẽ bị thu hút bởi chất lượng của nó và viết các ứng dụng tuyệt vời cho nó, mang lại cho bạn rất nhiều tiền.
Bạn không bao giờ tưởng tượng người khác có thể sử dụng API của bạn như thế nào. Đây là những gì đã xảy ra với Kinect. Ban đầu, Microsoft đã tạo Kinect cho các trò chơi. Khi Microsoft mở API ra công chúng, họ không bao giờ tưởng tượng nó sẽ được sử dụng vài năm sau đó bởi các ứng dụng khoa học, ngành y tế, v.v. Nó tương tự đối với API web: nhiều nhà phát triển đang sử dụng nó, sẽ có nhiều ý tưởng hơn.