Bảng tóm tắt về thiết kế hệ thống: Kiểu API - REST, GraphQL, WebSocket, Webhook, RPC/gRPC, SOAP

Đây là phần tiếp theo của một loạt bài viết trong đó tôi trình bày ngắn gọn những điểm chính của một chủ đề cụ thể trong thiết kế kiến trúc hệ thống. Bài viết đầu tiên có thể được đọc ở đây Kiến trúc API đề cập đến tập hợp các quy tắc, giao thức và công cụ quy định cách các thành phần phần mềm tương tác. Kiến trúc của API không chỉ tạo điều kiện thuận lợi cho việc giao tiếp; đó còn là việc đảm bảo rằng hoạt động liên lạc này hiệu quả, an toàn và có thể mở rộng. Kiến trúc API được thiết kế tốt có thể nâng cao đáng kể hiệu suất của hệ thống, trong khi kiến trúc được thiết kế kém có thể dẫn đến tắc nghẽn, lỗ hổng bảo mật và những cơn ác mộng khi bảo trì. Các kiểu kiến trúc API khác nhau Các kiểu thiết kế API phổ biến nhất: (Chuyển trạng thái đại diện) là kiểu được sử dụng nhiều nhất sử dụng các phương thức tiêu chuẩn và giao thức HTTP. Nó dựa trên các nguyên tắc như không trạng thái, kiến trúc máy khách-máy chủ và khả năng lưu vào bộ nhớ đệm. Nó thường được sử dụng giữa các máy khách phía trước và các dịch vụ phía sau. REST là ngôn ngữ truy vấn dành cho API. Không giống như REST, hiển thị một tập hợp điểm cuối cố định cho từng tài nguyên, GraphQL cho phép khách hàng yêu cầu chính xác dữ liệu họ cần, giảm việc tìm nạp quá mức. GraphQL là một giao thức cho phép giao tiếp hai chiều qua TCP. Khách hàng sử dụng ổ cắm web để nhận các bản cập nhật theo thời gian thực từ các hệ thống phụ trợ. WebSocket là cơ chế cho phép một hệ thống thông báo cho hệ thống khác về các sự kiện cụ thể trong thời gian thực. Đó là một cuộc gọi lại HTTP do người dùng xác định. Webhook là giao thức mà một dịch vụ có thể sử dụng để yêu cầu một quy trình/phương thức từ một dịch vụ nằm trên một máy tính khác trong mạng. Thông thường, nó được thiết kế để liên lạc với độ trễ thấp, tốc độ cao. RPC (gRPC) là một giao thức trao đổi thông tin có cấu trúc để triển khai các dịch vụ web. Nó dựa trên XML và được biết đến với các tính năng bảo mật và mạnh mẽ, hiện được coi là một giao thức cũ. SOAP Chúng ta hãy xem xét từng giao thức riêng biệt với tất cả ưu, nhược điểm và trường hợp sử dụng của chúng. NGHỈ NGƠI là một kiểu kiến trúc sử dụng các quy ước và giao thức tiêu chuẩn, giúp dễ hiểu và thực hiện. Bản chất không trạng thái và việc sử dụng các phương thức HTTP tiêu chuẩn khiến nó trở thành lựa chọn phổ biến để xây dựng các API dựa trên web. REST Mặc dù REST đã trở thành tiêu chuẩn thực tế để xây dựng API trong một thời gian dài, nhưng các phong cách khác như GraphQL đã xuất hiện, cung cấp các mô hình khác nhau để truy vấn và thao tác dữ liệu. : XML, JSON, HTML, văn bản thuần túy Định dạng : HTTP/HTTPS Giao thức truyền tải Các khái niệm và đặc điểm chính : Trong REST, mọi thứ đều là tài nguyên. Tài nguyên là một đối tượng có loại, dữ liệu liên quan, mối quan hệ với các tài nguyên khác và một tập hợp các phương thức hoạt động trên nó. Tài nguyên được xác định bằng URI của chúng (thường là URL). Tài nguyên : Các dịch vụ REST thường ánh xạ trực tiếp tới các hoạt động CRUD (Tạo, Đọc, Cập nhật, Xóa) trên tài nguyên. Hoạt động CRUD : Hệ thống REST sử dụng các phương thức HTTP tiêu chuẩn: Phương thức HTTP NHẬN: Truy xuất tài nguyên. POST: Tạo một tài nguyên mới. PUT/PATCH: Cập nhật tài nguyên hiện có. DELETE: Xóa tài nguyên. : API REST sử dụng mã trạng thái HTTP tiêu chuẩn để cho biết sự thành công hay thất bại của yêu cầu API: Mã trạng thái 2xx - Thừa nhận và thành công 200 - được rồi 201 - Tạo 202 - Đã chấp nhận 3xx - Chuyển hướng 301 - Đã di chuyển vĩnh viễn 302 - Đã tìm thấy 303 - Xem thêm 4xx - Lỗi máy khách 400 - Yêu cầu không hợp lệ 401 - Không được phép 403 - Bị cấm 404 không tìm thấy 405 - Phương pháp không được phép 5xx - Lỗi máy chủ 500 - Lỗi máy chủ nội bộ 501 - Chưa thực hiện 502 - Cổng xấu Lỗi 503: Dịch vụ không khả dụng 504 - Hết thời gian chờ cổng : Mỗi yêu cầu từ máy khách đến máy chủ phải chứa tất cả thông tin cần thiết để hiểu và xử lý yêu cầu. Máy chủ không được lưu trữ bất cứ điều gì về trạng thái của máy khách giữa các yêu cầu. Không trạng thái : REST dựa trên mô hình client-server. Máy khách chịu trách nhiệm về giao diện và trải nghiệm người dùng, trong khi máy chủ chịu trách nhiệm xử lý các yêu cầu, xử lý logic nghiệp vụ và lưu trữ dữ liệu. Client-Server : Các phản hồi từ máy chủ có thể được máy khách lưu vào bộ nhớ đệm. Máy chủ phải cho biết liệu phản hồi có được lưu vào bộ nhớ đệm hay không. Có thể lưu vào bộ nhớ đệm : Thông thường, máy khách không thể biết liệu nó được kết nối trực tiếp với máy chủ cuối hay máy trung gian. Máy chủ trung gian có thể cải thiện khả năng mở rộng hệ thống bằng cách cho phép cân bằng tải và cung cấp bộ nhớ đệm dùng chung. Hệ thống phân lớp Hypermedia As The Engine Of Application Stat là một nguyên tắc dịch vụ web REST cho phép khách hàng tương tác và điều hướng qua một ứng dụng web hoàn toàn dựa trên hypermedia được máy chủ cung cấp linh hoạt trong các phản hồi của nó, thúc đẩy khả năng kết nối và khám phá lỏng lẻo. HATEOAS: Trường hợp sử dụng : Nhiều dịch vụ web thể hiện chức năng của chúng thông qua API REST, cho phép các nhà phát triển bên thứ ba tích hợp và mở rộng dịch vụ của họ. Dịch vụ web : Ứng dụng di động thường giao tiếp với máy chủ phụ trợ bằng API REST để tìm nạp và gửi dữ liệu. Ứng dụng di động : SPA sử dụng API REST để tải động nội dung mà không yêu cầu làm mới toàn bộ trang. Ứng dụng một trang (SPA) Các hệ thống trong tổ chức có thể giao tiếp và chia sẻ dữ liệu bằng API REST. Tích hợp giữa các hệ thống: Ví dụ Lời yêu cầu NHẬN “/người dùng/42” Phản ứng { "id": 42, "name": "Alex", "links": { "role": "/user/42/role" } } GraphQL cung cấp cách tiếp cận linh hoạt, mạnh mẽ và hiệu quả hơn để xây dựng API, đặc biệt là trong các hệ thống phức tạp hoặc khi giao diện người dùng cần tính linh hoạt cao. Nó chuyển một số trách nhiệm từ máy chủ sang máy khách, cho phép máy khách chỉ định các yêu cầu dữ liệu của mình. GraphQL Mặc dù nó không phải là sự thay thế cho REST trong mọi tình huống nhưng nó cung cấp một giải pháp thay thế hấp dẫn trong nhiều tình huống, đặc biệt khi các ứng dụng trở nên được nối mạng và phân tán nhiều hơn. : JSON Định dạng : HTTP/HTTPS Giao thức truyền tải Các khái niệm và đặc điểm chính : Nó cho phép khách hàng yêu cầu dữ liệu họ cần, giúp có thể nhận được tất cả thông tin cần thiết trong một yêu cầu duy nhất. Ngôn ngữ truy vấn dành cho API : API GraphQL được sắp xếp theo loại và trường chứ không phải điểm cuối. Nó sử dụng một hệ thống kiểu mạnh để xác định các khả năng của API. Tất cả các loại được hiển thị trong API đều được ghi lại trong một lược đồ bằng cách sử dụng Ngôn ngữ định nghĩa lược đồ GraphQL (SDL). Hệ thống loại : Không giống như REST, nơi bạn có thể có nhiều điểm cuối cho các tài nguyên khác nhau, trong GraphQL, bạn thường hiển thị một điểm cuối duy nhất thể hiện bộ khả năng hoàn chỉnh của dịch vụ. Điểm cuối duy nhất : Về phía máy chủ, bộ phân giải thu thập dữ liệu được mô tả trong truy vấn. Bộ phân giải : Ngoài việc chỉ truy vấn dữ liệu, GraphQL còn bao gồm hỗ trợ tích hợp cho các cập nhật theo thời gian thực bằng cách sử dụng đăng ký. Cập nhật theo thời gian thực với đăng ký : Máy chủ GraphQL có thể được truy vấn về các loại mà nó hỗ trợ. Điều này tạo ra một hợp đồng mạnh mẽ giữa máy khách và máy chủ, cho phép tạo công cụ và xác thực tốt hơn. Nội tâm Trường hợp sử dụng : Đối với các ứng dụng (đặc biệt là thiết bị di động) có băng thông quan trọng, bạn muốn giảm thiểu dữ liệu được tìm nạp từ máy chủ. Giao diện người dùng linh hoạt : Bạn có thể giới thiệu lớp GraphQL để tổng hợp dữ liệu từ các dịch vụ này thành một API hợp nhất nếu bạn có nhiều dịch vụ vi mô. Tổng hợp các dịch vụ vi mô : Với hệ thống đăng ký, GraphQL có thể rất phù hợp cho các ứng dụng cần dữ liệu thời gian thực, như ứng dụng trò chuyện, cập nhật thể thao trực tiếp, v.v. Ứng dụng thời gian thực : Với REST, bạn thường cần lập phiên bản API của mình sau khi có thay đổi. Với GraphQL, máy khách chỉ yêu cầu dữ liệu cần thiết nên việc thêm trường hoặc loại mới sẽ không tạo ra những thay đổi đột phá. API không có phiên bản Ví dụ Lời yêu cầu NHẬN “/graphql?query=user(id:42){ tên vai trò { tên id } }” Phản ứng { "data": { "user": { "id": 42, "name": "Alex", "role": { "id": 1, "name": "admin" } } } } WebSocket cung cấp kênh liên lạc song công hoàn toàn qua một kết nối lâu dài, cho phép trao đổi dữ liệu theo thời gian thực giữa máy khách và máy chủ. Điều này làm cho nó trở nên lý tưởng cho các ứng dụng web có tính tương tác và hiệu suất cao. WebSockets : Nhị phân Định dạng : TCP Giao thức vận chuyển Các khái niệm và đặc điểm chính : Không giống như mô hình phản hồi yêu cầu truyền thống, WebSockets cung cấp kênh liên lạc song công hoàn toàn vẫn mở, cho phép trao đổi dữ liệu theo thời gian thực. Kết nối liên tục : WebSockets bắt đầu dưới dạng một yêu cầu HTTP, sau đó được nâng cấp lên kết nối WebSocket nếu máy chủ hỗ trợ. Việc này được thực hiện thông qua tiêu đề `Nâng cấp`. Nâng cấp Handshake : Sau khi kết nối được thiết lập, dữ liệu sẽ được truyền dưới dạng khung. Cả dữ liệu văn bản và nhị phân đều có thể được gửi qua các khung này. Khung : WebSockets cho phép liên lạc trực tiếp giữa máy khách và máy chủ mà không cần phải mở kết nối mới cho mỗi lần trao đổi. Điều này dẫn đến việc trao đổi dữ liệu nhanh hơn. Độ trễ thấp : Cả máy khách và máy chủ đều có thể gửi tin nhắn cho nhau một cách độc lập. Hai chiều : Sau kết nối ban đầu, các khung dữ liệu yêu cầu gửi ít byte hơn, dẫn đến ít chi phí hơn và hiệu suất tốt hơn so với việc thiết lập kết nối HTTP nhiều lần. Ít chi phí hơn : WebSockets hỗ trợ các giao thức con và tiện ích mở rộng, cho phép các giao thức được tiêu chuẩn hóa và tùy chỉnh trên giao thức WebSocket cơ bản. Giao thức và tiện ích mở rộng Trường hợp sử dụng : Trò chơi nhiều người chơi trong thời gian thực trong đó hành động của người chơi phải được phản ánh ngay lập tức tới những người chơi khác. Trò chơi trực tuyến : Các ứng dụng như Google Docs, nơi nhiều người dùng có thể chỉnh sửa tài liệu cùng lúc và xem những thay đổi của nhau trong thời gian thực. Công cụ cộng tác : Nền tảng giao dịch chứng khoán nơi giá cổ phiếu cần được cập nhật theo thời gian thực. Ứng dụng tài chính : Bất kỳ ứng dụng nào mà người dùng cần nhận thông báo theo thời gian thực, chẳng hạn như nền tảng truyền thông xã hội hoặc ứng dụng nhắn tin. Thông báo : Các trang web tin tức hoặc nền tảng truyền thông xã hội nơi các bài đăng hoặc cập nhật mới được phát trực tiếp tới người dùng. Nguồn cấp dữ liệu trực tiếp Ví dụ Lời yêu cầu NHẬN “ws://site:8181” Phản ứng Giao thức chuyển đổi HTTP/1.1 101 Webhook là một lệnh gọi lại HTTP do người dùng xác định được kích hoạt bởi các sự kiện ứng dụng web cụ thể, cho phép tích hợp và cập nhật dữ liệu theo thời gian thực giữa các hệ thống khác nhau. Webhook : XML, JSON, văn bản thuần túy Định dạng : HTTP/HTTPS Giao thức truyền tải Các khái niệm và đặc điểm chính : Webhooks thường được sử dụng để biểu thị rằng một sự kiện đã xảy ra. Thay vì yêu cầu dữ liệu theo định kỳ, webhook cung cấp dữ liệu ngay khi dữ liệu diễn ra, thay đổi mô hình phản hồi yêu cầu truyền thống. Hướng sự kiện : Webhooks về cơ bản là cơ chế gọi lại do người dùng xác định. Khi một sự kiện cụ thể xảy ra, trang nguồn sẽ thực hiện lệnh gọi lại HTTP tới URI do trang đích cung cấp, sau đó sẽ thực hiện một hành động cụ thể. Cơ chế gọi lại : Khi webhook được kích hoạt, site nguồn sẽ gửi dữ liệu (payload) đến site đích. Dữ liệu này thường ở dạng JSON hoặc XML. Payload : Webhooks cho phép các ứng dụng nhận dữ liệu theo thời gian thực, khiến chúng có độ phản hồi cao. Thời gian thực : Người dùng hoặc nhà phát triển thường có thể xác định những sự kiện cụ thể mà họ muốn được thông báo. Có thể tùy chỉnh : Vì webhooks liên quan đến việc thực hiện lệnh gọi lại tới các điểm cuối HTTP do người dùng xác định nên chúng có thể đặt ra những thách thức về bảo mật. Điều quan trọng là phải đảm bảo rằng điểm cuối được an toàn, dữ liệu được xác thực và có thể được mã hóa. Bảo mật Trường hợp sử dụng : Kích hoạt các bản dựng và triển khai khi mã được đẩy hoặc yêu cầu kéo được hợp nhất. Tích hợp và triển khai liên tục (CI/CD) : Thông báo cho hệ thống hạ nguồn khi nội dung được cập nhật, xuất bản hoặc xóa. Hệ thống quản lý nội dung (CMS) : Thông báo cho các nền tảng thương mại điện tử về kết quả giao dịch, chẳng hạn như thanh toán thành công, giao dịch không thành công hoặc hoàn tiền. Cổng thanh toán : Nhận thông báo về bài đăng mới, đề cập hoặc các sự kiện có liên quan khác trên nền tảng truyền thông xã hội. Tích hợp phương tiện truyền thông xã hội : Các thiết bị hoặc cảm biến có thể kích hoạt webhooks để thông báo cho các hệ thống hoặc dịch vụ khác về các sự kiện hoặc việc đọc dữ liệu cụ thể. IoT (Internet of Things) Ví dụ Lời yêu cầu NHẬN “ ” https://external-site/webhooks?url=http://site/service-h/api&name=name Phản ứng { "webhook_id": 12 } RPC và gRPC (Cuộc gọi thủ tục từ xa) là một giao thức cho phép chương trình thực thi một thủ tục hoặc chương trình con trong một không gian địa chỉ khác, cho phép liên lạc và trao đổi dữ liệu liền mạch giữa các hệ thống phân tán. RPC (Google RPC) là một khung mã nguồn mở hiện đại được xây dựng dựa trên RPC sử dụng HTTP/2 để truyền tải và Bộ đệm giao thức làm ngôn ngữ mô tả giao diện, cung cấp các tính năng như xác thực, cân bằng tải, v.v. để hỗ trợ giao tiếp hiệu quả và mạnh mẽ giữa các microservice. gRPC RPC : JSON, XML, Protobuf, Thrift, FlatBuffers Định dạng : Khác nhau Giao thức vận chuyển Các khái niệm và đặc điểm chính : RPC cho phép một chương trình khiến một thủ tục (chương trình con) thực thi trong một không gian địa chỉ khác (thường là trên một máy tính khác trên mạng dùng chung). Nó giống như gọi một chức năng được thực hiện trên một máy khác với máy của người gọi. Định nghĩa : Trong ngữ cảnh của RPC, sơ khai là các đoạn mã được tạo bởi các công cụ cho phép các lệnh gọi thủ tục cục bộ và từ xa xuất hiện giống nhau. Máy khách có một sơ khai trông giống như thủ tục từ xa và máy chủ có một sơ khai giải nén các đối số, gọi thủ tục thực tế rồi đóng gói kết quả để gửi lại. Sơ khai : Các cuộc gọi RPC truyền thống đang bị chặn, nghĩa là máy khách gửi yêu cầu đến máy chủ và bị chặn khi chờ phản hồi từ máy chủ. Đồng bộ theo mặc định : Nhiều hệ thống RPC cho phép triển khai máy khách và máy chủ khác nhau giao tiếp bất kể chúng được viết bằng ngôn ngữ nào. Ngôn ngữ trung lập : RPC thường yêu cầu máy khách và máy chủ biết thủ tục được gọi, các tham số và kiểu trả về của nó. Khớp nối chặt chẽ Trường hợp sử dụng : RPC thường được sử dụng trong các hệ thống phân tán trong đó các bộ phận của hệ thống được trải rộng trên các máy hoặc mạng khác nhau nhưng cần liên lạc như thể chúng là cục bộ. Hệ thống phân tán : NFS (Hệ thống tệp mạng) là một ví dụ về RPC thực hiện các thao tác tệp từ xa. Hệ thống tệp mạng Ví dụ Lời yêu cầu { "method": "addUser", "params": [ "Alex" ] } Phản ứng { "id": 42, "name": "Alex", "error": null } gRPC : Protobuf Định dạng : HTTP/2 Giao thức vận chuyển Các khái niệm và đặc điểm chính : gRPC là một khung RPC nguồn mở được phát triển bởi Google. Nó sử dụng HTTP/2 để truyền tải, Bộ đệm giao thức (Protobuf) làm ngôn ngữ mô tả giao diện và cung cấp tính năng xác thực, cân bằng tải, v.v. Định nghĩa : Đây là một cơ chế có thể mở rộng, trung lập về ngôn ngữ, nền tảng để tuần tự hóa dữ liệu có cấu trúc. Với gRPC, bạn xác định các phương thức dịch vụ và loại thông báo bằng Protobuf. Bộ đệm giao thức : gRPC được thiết kế để truyền thông có độ trễ thấp và thông lượng cao. HTTP/2 cho phép ghép nhiều cuộc gọi qua một kết nối duy nhất và giảm chi phí hoạt động. Hiệu suất : gRPC hỗ trợ truyền phát các yêu cầu và phản hồi, cho phép thực hiện các trường hợp sử dụng phức tạp hơn như kết nối lâu dài, cập nhật theo thời gian thực, v.v. Truyền phát : gRPC cho phép khách hàng chỉ định khoảng thời gian họ sẽ đợi một RPC hoàn thành. Máy chủ có thể kiểm tra điều này và quyết định nên hoàn thành thao tác hay hủy bỏ nếu quá trình này có thể mất quá nhiều thời gian. Thời hạn/Hết thời gian : gRPC được thiết kế để hỗ trợ xác thực có thể cắm, cân bằng tải, thử lại, v.v. Có thể cắm : Giống như RPC, gRPC là ngôn ngữ bất khả tri. Tuy nhiên, với Protobuf và công cụ gRPC, việc tạo mã máy khách và máy chủ bằng nhiều ngôn ngữ thật dễ dàng. Ngôn ngữ trung lập Trường hợp sử dụng : gRPC thường được sử dụng trong các kiến trúc microservice do đặc tính hiệu suất và khả năng xác định hợp đồng dịch vụ một cách dễ dàng. Microservices : Với khả năng hỗ trợ phát trực tuyến, gRPC phù hợp với các ứng dụng thời gian thực nơi máy chủ đẩy dữ liệu đến máy khách trong thời gian thực. Ứng dụng thời gian thực : Lợi ích về hiệu suất và khả năng phát trực tuyến của gRPC khiến nó phù hợp với các khách hàng di động giao tiếp với các dịch vụ phụ trợ. Khách hàng di động Ví dụ message User { int id = 1 string name = 2 } service UserService { rpc AddUser(User) returns (User); } XÀ BÔNG , viết tắt của Simple Object Access Protocol, là một giao thức trao đổi thông tin có cấu trúc để triển khai các dịch vụ web trong mạng máy tính. Đó là một giao thức dựa trên XML cho phép các chương trình chạy trên các hệ điều hành khác nhau giao tiếp với nhau. SOAP : XML Định dạng : HTTP/HTTPS, JMS, SMTP, v.v. Giao thức truyền tải Các khái niệm và đặc điểm chính : Các thông báo SOAP được định dạng bằng XML và chứa các thành phần sau: Dựa trên XML : Phần tử gốc của thông báo SOAP xác định tài liệu XML là thông báo SOAP. Phong bì : Chứa bất kỳ thuộc tính tùy chọn nào của tin nhắn được sử dụng để xử lý tin nhắn, tại điểm trung gian hoặc điểm cuối cuối cùng. Tiêu đề : Chứa dữ liệu XML bao gồm tin nhắn được gửi. Nội dung : Phần tử Lỗi tùy chọn cung cấp thông tin về lỗi trong khi xử lý thông báo. Lỗi : SOAP có thể được sử dụng với bất kỳ mô hình lập trình nào và không bị ràng buộc với một mô hình cụ thể. Tính trung lập : Nó có thể chạy trên mọi hệ điều hành và bằng mọi ngôn ngữ. Độc lập : Mỗi yêu cầu từ máy khách đến máy chủ phải chứa tất cả thông tin cần thiết để hiểu và xử lý yêu cầu. Không trạng thái : Phần tử Lỗi trong thông báo SOAP được sử dụng để báo cáo lỗi. Xử lý lỗi tích hợp : Hoạt động dựa trên các tiêu chuẩn được xác định rõ ràng, bao gồm cả đặc tả SOAP, cũng như các tiêu chuẩn liên quan như WS-ReliableMessaging để đảm bảo gửi tin nhắn, WS-Security để bảo mật tin nhắn, v.v. Được tiêu chuẩn hóa Trường hợp sử dụng : SOAP thường được sử dụng trong cài đặt doanh nghiệp do tính mạnh mẽ, khả năng mở rộng và khả năng vượt qua tường lửa và proxy của nó. Ứng dụng doanh nghiệp : Nhiều dịch vụ web, đặc biệt là những dịch vụ cũ hơn, sử dụng SOAP. Điều này bao gồm các dịch vụ được cung cấp bởi các công ty lớn như Microsoft và IBM. Dịch vụ web : Tính bảo mật và khả năng mở rộng tích hợp của SOAP khiến nó trở thành lựa chọn tốt cho các giao dịch tài chính, trong đó tính toàn vẹn và bảo mật dữ liệu là tối quan trọng. Giao dịch tài chính : Các công ty viễn thông có thể sử dụng SOAP cho các quy trình như thanh toán, trong đó các hệ thống khác nhau phải giao tiếp một cách đáng tin cậy. Viễn thông Ví dụ Lời yêu cầu Alex Phản ứng 42 Alex Phần kết luận Bối cảnh của các kiểu kiến trúc API rất đa dạng, cung cấp nhiều cách tiếp cận khác nhau như REST, SOAP, RPC, v.v., mỗi cách đều có điểm mạnh và trường hợp sử dụng riêng, cho phép các nhà phát triển chọn mô hình phù hợp nhất để xây dựng các tích hợp mạnh mẽ, hiệu quả và có thể mở rộng giữa các phần mềm khác nhau các thành phần và hệ thống.