Kiến trúc API bên trong và bên ngoài

Công ty tôi làm việc để duy trì một sản phẩm SaaS thành công đã phát triển "hữu cơ" trong những năm qua. Chúng tôi đang lên kế hoạch mở rộng dòng sản phẩm với bộ sản phẩm mới sẽ chia sẻ dữ liệu với sản phẩm hiện có. Để hỗ trợ điều này, chúng tôi đang tìm cách hợp nhất logic kinh doanh vào một nơi duy nhất: một lớp dịch vụ web. Lớp WS sẽ được sử dụng bởi:

• Các ứng dụng web
• Một công cụ để nhập dữ liệu
• Một công cụ để tích hợp với phần mềm máy khách khác (không phải API mỗi lần)

Chúng tôi cũng muốn tạo một API có thể được sử dụng bởi các khách hàng có khả năng sử dụng API để tạo tích hợp của riêng họ. Chúng tôi đang vật lộn với câu hỏi sau đây:

API nội bộ (còn gọi là lớp WS) và API bên ngoài phải giống nhau, với các cài đặt bảo mật và quyền để kiểm soát những gì có thể được thực hiện bởi ai hoặc chúng có thể là hai ứng dụng riêng biệt mà API bên ngoài chỉ gọi API bên trong như ứng dụng nào khác? Cho đến nay trong cuộc tranh luận của chúng tôi, dường như việc tách chúng có thể an toàn hơn, nhưng sẽ thêm chi phí.

Những người khác đã làm gì trong một tình huống tương tự?

Nó luôn luôn tốt để ăn thức ăn cho chó của riêng bạn. Một API cũng nên đơn giản hơn để duy trì hơn hai, ngay cả khi bạn tính đến một số chi phí để xác thực và ủy quyền.

Mặc dù tôi đồng ý với Aneurysm9 đôi khi bạn không muốn phơi bày tất cả các khả năng của hệ thống của mình. Trong trường hợp này, có hai API sẽ thích hợp hơn ... NHƯNG nếu bạn chọn cách này ... hãy đảm bảo rằng tất cả các chức năng phổ biến đều chia sẻ cùng một API, IE là một phiên bản mở rộng của cái kia chứ không phải là hai phiên bản khác biệt bộ mã.

Bằng cách này, bạn có thể tự mình sử dụng trong khi có một nơi dành cho công việc thử nghiệm, nhạy cảm, riêng tư để tiến bộ trong khi vẫn cho phép bạn xuất bản và sử dụng công cụ mới mà không thay đổi API công khai quá nhiều.

Tôi đã gặp điều này trước đây (nhiều lần) và điều cuối cùng tôi thích là:

Lấy BL ra khỏi trang web. Làm cho trang web trở thành người tiêu dùng của API. Hãy coi trang web như một số khách hàng khác của API của bạn. API của bạn là dịch vụ.

Nếu bạn thấy mình nghĩ rằng bạn cần các phương thức API đặc biệt chỉ dành cho trang web, hãy nghĩ lại! Nếu nó tốt cho ngỗng, thì tốt cho người ăn. Nếu bạn thực sự thực sự cần chức năng đặc biệt cho trang web, tôi sẽ đề xuất rằng những gì bạn thực sự tìm thấy là một sự khác biệt trong "hồ sơ người dùng" và do đó đây là tình huống mà API vẫn sẽ hỗ trợ các chức năng "đặc biệt", nhưng sau đó bạn kiểm soát chúng thông qua ủy quyền.

Không thuyết phục?

Đưa mô hình tiến thêm một bước ...

Ứng dụng điện thoại đang chạy trên một nền tảng nơi mã byte được thực thi, ứng dụng sống trong điện thoại và tiêu thụ các dịch vụ API thông qua HTTP / JSON

Trang web này là một ứng dụng chạy trên nền tảng trong đó HTML + Javascript được thực thi, ứng dụng nằm trong trình duyệt và sử dụng các dịch vụ API thông qua HTTP / JSON

Như nhau!

Mở rộng điều đó sang máy tính bảng, TV, nền tảng điện thoại khác, plugin, ứng dụng của bên thứ ba, mashup, ...

Rất nhiều trải nghiệm người dùng khác nhau đều được cắm vào một API chung.

Ứng dụng của bạn là API. Trang web này chỉ là một khách hàng (trong số nhiều)

Sử dụng một API

Nếu bạn đang triển khai API dịch vụ dưới dạng lớp REST, chỉ cần thêm xác thực vào các tuyến đường được bảo vệ.

Có lẽ bạn sẽ muốn sử dụng một khung phát triển không nướng quá nhiều 'ma thuật'. Một cái gì đó mà bạn có thể xác định tuyến đường trực tiếp mà không cần nhiều kỹ thuật đảo ngược.

Hãy suy nghĩ một cái gì đó như Node.js / Express, python / pylons, công cụ ứng dụng python / google, v.v.

Gần đây tôi đã triển khai điều này trên Google App Engine cho API REST / Datastore và tôi không nghĩ rằng nó có thể dễ dàng hơn. Các bộ điều khiển được triển khai như các lớp và các yêu cầu HTTP tiếp theo của chúng (tức là GET / POST / PUT / DELETE) được triển khai như các phương thức của các lớp đó. Tôi quản lý để thực hiện cơ bản-auth như một trang trí. Điều đó làm cho việc thêm một yêu cầu xác thực vào một yêu cầu đơn giản như đính kèm trang trí @basicAuth.

Bằng cách đó, tôi có thể thực hiện các yêu cầu GET đến công khai thêm yêu cầu xác thực vào các yêu cầu POST / PUT / DELETE trên cùng một bộ điều khiển cho mô hình đó.

Nếu bạn biết cách nói chuyện trong REST, cuộc sống trở nên dễ dàng hơn rất nhiều vì hỗ trợ REST vốn đã được đưa vào máy chủ web (tức là HTTP chỉ là một loại API REST). Bạn thậm chí có thể chọn nén gzip trong suốt nếu bạn gửi nhiều dữ liệu qua dây.

Ấn tượng đầu tiên của tôi là nó phải là cùng một API và bảo mật của bạn phải ở trên một lớp khác hoàn toàn. Có lẽ được xử lý bởi một mặt trận web?