Tại sao nên sử dụng dịch vụ (REST / SOAP) thay vì thư viện?

Giả sử bạn đang xem xét việc chia nhỏ các ứng dụng của mình thành các dịch vụ. Có bất kỳ lý do chính đáng nào để áp dụng cách tiếp cận SOA so với việc tạo API thư viện có thể được tải bởi các ứng dụng cần nó.

Sự khác biệt có thể là tinh tế giữa cả hai. Ví dụ, trong thế giới .NET, bạn có thể có một ứng dụng giống như người dùng cuối và sẽ hoạt động trên cùng một máy, nhưng bên trong, sẽ được tách thành một loạt các dịch vụ WCF. Bạn cũng có thể có kiến ​​trúc nơi các thư viện không được liên kết mạnh (addins / plugin) và chỉ theo một giao thức khi nói chuyện với nhau.

Nếu chúng tôi tránh nói về các trường hợp trung gian đó và chỉ giải quyết với thư viện API được liên kết mạnh so với dịch vụ REST riêng biệt, thì bạn có thể muốn xem xét các điểm sau:

1. API thư viện được gọi trên cùng một máy. Dịch vụ có thể được lưu trữ ở bất cứ đâu và được gọi từ bất cứ đâu. Nếu bạn đang đếm việc lưu trữ ứng dụng trên nhiều máy vì lý do hiệu năng / khả năng mở rộng / bảo mật, rất có thể bạn sẽ cần sử dụng dịch vụ.

2. Tình huống tương tự khi sử dụng một dịch vụ bởi một ứng dụng được triển khai trên một số máy. Ví dụ: nếu bạn đang làm một ứng dụng cho ngân hàng thực hiện một số tính toán tài chính, một cách là triển khai toàn bộ ứng dụng lớn cho mọi máy tính để bàn và buộc phải cập nhật quy mô lớn cho mọi khách hàng mọi lúc; một cách tiếp cận khác là lưu trữ phần tính toán trên các máy chủ và triển khai lên máy tính để bàn chỉ là một ứng dụng nhẹ chỉ với một giao diện người dùng và một loạt các cuộc gọi đến các máy chủ đó.

3. Nếu bạn đang lưu trữ dịch vụ REST, bất kỳ ai cũng có thể sử dụng dịch vụ này: người dùng Mac, người sử dụng Linux, v.v. Nếu bạn đã tạo thư viện C # với Visual Studio và bạn phân phối dưới dạng DLL, hãy quên người dùng (khách hàng ?) ai không có Windows.

Một ưu điểm khác của dịch vụ là khi bạn cập nhật dịch vụ, nó sẽ được triển khai ngay lập tức cho tất cả người tiêu dùng dịch vụ. Vì vậy, nếu bạn đã sửa lỗi hoặc vấn đề về hiệu năng, mọi người đều nhận được lợi ích ngay khi dịch vụ cập nhật được phát hành, thay vì phải phân phối bản cập nhật mà mọi người có thể chọn bỏ qua.

Ưu điểm của thư viện:

• Chi phí thấp hơn cho mỗi cuộc gọi (chỉ nhảy hoặc thậm chí nội tuyến ) = có thể tăng hiệu suất
• Điều đơn giản nhất có thể làm việc
• Không có nguy cơ dịch vụ tập trung đi xuống và ảnh hưởng đến tất cả người tiêu dùng

Ưu điểm dịch vụ:

• Mọi người đều được nâng cấp ngay lập tức và minh bạch (trừ khi API phiên bản bị tắt)
• Người tiêu dùng không thể dịch ngược mã
• Có thể chia tỷ lệ phần cứng dịch vụ riêng
• Công nghệ bất khả tri. Với một thư viện chia sẻ, người tiêu dùng phải sử dụng một công nghệ tương thích.
• An toàn hơn. Tầng UI có thể gọi dịch vụ nằm phía sau tường lửa thay vì truy cập trực tiếp vào DB.

Một cách tiếp cận SOA cho phép các dịch vụ khác nhau được lưu trữ và duy trì một cách riêng biệt. Ngoài mã, việc triển khai một dịch vụ cụ thể có thể yêu cầu rất nhiều cấu hình đặc biệt (mật khẩu, cổng, chứng chỉ, v.v.). Việc sử dụng một dịch vụ REST có độ phức tạp hữu hạn có thể được ghi lại rõ ràng và dễ hiểu. Nó cũng an toàn hơn vì điều đó có nghĩa là bạn không cần cấp quyền truy cập vào DB hoặc các tài nguyên khác cho khách hàng.

Nếu có một sự thay đổi đối với một dịch vụ SOA, thì dịch vụ đó sẽ phải được phát triển lại, kiểm tra lại và triển khai lại. Tất cả các ứng dụng tiêu thụ dịch vụ đó có thể tiếp tục làm như vậy. Thay đổi thư viện trong DLL sẽ có nghĩa là tất cả người tiêu dùng của thư viện đó sẽ phải được phát triển lại để tham chiếu DLL đó, tất cả họ sẽ phải được kiểm tra lại và tất cả họ sẽ phải triển khai lại. Ngoài ra còn có nguy cơ điều này có thể không xảy ra đúng, và các ứng dụng khác nhau sẽ có các phiên bản khác nhau của DLL. Đôi khi điều này có thể không phải là vấn đề - có lẽ mọi hệ thống nên có phiên bản thư viện có mặt tại thời điểm triển khai (bạn có thể đã cập nhật hệ thống ghi nhật ký của mình để có các tính năng mới hữu ích - bạn có thực sựcần cập nhật mọi hệ thống với nó?) trong trường hợp này một thư viện vẫn ổn. Nhưng nói rằng bạn có một dịch vụ để tính thuế suất, và luật thuế thay đổi. Bạn không muốn phải cập nhật mọi hệ thống để kết hợp thay đổi này, sẽ tốt hơn nếu thực hiện ở một nơi. Trong trường hợp này, một dịch vụ là một lựa chọn tốt hơn.

Có một số câu trả lời hay nhưng tôi muốn thêm nhiều thứ vào câu trả lời đã cho:

Phương thức thư viện API rất hữu ích khi bạn muốn tương tác với mọi thứ với càng ít chi phí càng tốt. Hậu quả là có sự kết hợp cao hơn giữa API và các ứng dụng sử dụng nó. Đôi khi, điều này là ổn đối với ứng dụng và thậm chí là cần thiết, tuy nhiên nếu bạn có một hệ thống phân tán hoặc bạn nghĩ rằng khả năng tương tác là một vấn đề lớn, bạn có thể cần phải tiến lên một bước trừu tượng sau và sử dụng các cách giao tiếp khác. Đặc biệt, nếu bạn muốn có một hệ thống phân tán, SOAP là loại bước tiếp theo trong SOA, nhưng bạn vẫn sẽ bị phụ thuộc giữa các đơn vị, vì chúng phải biết các thủ tục khác. REST đưa nó lên một cấp độ mới, bằng cách cho phép một cỗ máy tìm hiểu điều gì đó về nội dung trên các dịch vụ khác theo cách thống nhất.

Trong trường hợp của bạn, nếu ứng dụng của bạn không được phân phối, tôi không thấy bất kỳ lý do nào để chuyển đổi ứng dụng của bạn thành SOA.