Phân nhóm và lồng các API REST

Câu hỏi của tôi là xung quanh thực tiễn tốt nhất về tổng hợp hoặc nhóm các API REST. Tôi có một kịch bản có nhiều nhà cung cấp, nguồn dữ liệu khác nhau, v.v. và tôi nghĩ việc nhóm các API REST sẽ có ý nghĩa rất lớn để giữ cho hệ thống duy trì được.

Tôi có nhiều kịch bản trong đó sẽ có một lệnh gọi API kích hoạt nhiều lệnh gọi API (tương tự) khác để tạo cùng một thực thể trong một hệ thống khác . Ví dụ cho một thực thể ví dụ "người dùng" :

1. Giao diện người dùng gọi API REST: PUT ... / người dùng
2. Những gì tôi hình dung là mã nghe trên API ở trên sau đó sẽ thực hiện nhiều lệnh gọi REST PUT để giả sử nhà cung cấp / người dùng, nhà cung cấp / người dùng, nhà cung cấp / người dùng, InternalSystemA / người dùng, InternalSystemB / người dùng, v.v.

Như thế này:

                                                            +-------------------+              
+--------+                   PUT     +-----------+  CALL    | Vendor A API      |              
|        |                 +-------> | user      +--------> |                   |              
|        |                 |         +-----------+          +-------------------+              
|        |                 |                                                                   
| Front  | PUT    +--------++  PUT   +-----------+  INSERT  +-------------------+              
| End    +------> | user    +------> | user      +--------> | Internal System   |              
|        |        +--------++        +-----------+          +-------------------+              
|        |                 |                                                                   
|        |                 |         +-----------+  CALL    +-------------------+              
|        |                 +-------> | user      +--------> | Vendor B API      |              
+--------+                   PUT     +-----------+          |                   |              
                                                            +-------------------+             
                 +                                 +                                           
                 +---------------------------------+                                           
                         Internal REST APIs                                                    

Lưu ý rằng thực thể mẫu không nhất thiết phải là "người dùng", có nhiều thực thể sẽ có đối tác trên API của nhà cung cấp.

Các nhà cung cấp trong kịch bản này cung cấp chức năng khác nhau. Nhưng có thể có nhiều nhà cung cấp cung cấp cùng chức năng (và người dùng sẽ chọn nhà cung cấp mà anh ta muốn sử dụng). Để đơn giản, hãy nói các chức năng ví dụ là

• Tạp vụ,
• Nguồn nhân lực,
• Sự quản lý,
• Thanh toán.

Cách thực hành tốt nhất để nhóm và lồng các API REST trong kịch bản như vậy là gì? Có phải là một ý tưởng tốt để nhóm chúng theo nhà cung cấp hoặc chúng nên được nhóm chức năng hoặc theo thực thể kinh doanh? URL sẽ trông như thế nào?

Tôi muốn đi nhóm hợp lý hơn,

Hãy tưởng tượng một hệ thống nơi thực hiện đặt phòng khách sạn, nơi có 2 API đặt phòng khách sạn (A và B) khác nhau và một cổng thanh toán.

Trong tình huống này, một vài thực hành tốt nhất sẽ tuân theo,

• Gói bất kỳ API của bên thứ ba vào một trong các dịch vụ (bất cứ khi nào API của bên thứ ba thay đổi chỉ cần thay đổi dịch vụ trình bao bọc), trong ví dụ này, giao diện đơn có thể được sử dụng cho cả dịch vụ A và B.
• Tạo mặt tiền dịch vụ cấp cao hơn dựa trên chức năng (trong trường hợp này là mặt tiền để tìm kiếm và mặt tiền để đặt chỗ)
• Điều này cũng sẽ giúp khắc phục sự cố, bởi vì nếu có lỗi, nó sẽ dễ dàng theo dõi toàn bộ quá trình vì nó xảy ra trong một phương thức mặt tiền duy nhất

Câu trả lời phụ thuộc vào một số giả định không được mô tả trong câu hỏi: 1. Bạn không có quyền tự do thay đổi nhà cung cấp hoặc API nội bộ 2. Việc phân nhóm phải được thực hiện trong một giao dịch. tức là, API nên nghiêm ngặt như thế nào đối với các lỗi của nhà cung cấp. Điều gì xảy ra nếu 1 nhà cung cấp thất bại và phần còn lại thành công. Chúng tôi vẫn coi đây là thành công hay khởi tạo API rollback (ví dụ: xóa người dùng)

Dựa trên các giả định, tôi sẽ không thiết kế API của mình dựa trên việc triển khai, chẳng hạn như có API của nhà cung cấp, v.v., nhưng hoàn toàn dựa trên chức năng, tức là ai là người dùng API mới và các yêu cầu của họ.