Outlook REST API vs Microsoft Graph

Question

tôi đang làm việc trên một ứng dụng mà cần phải lấy và chỉnh sửa sự kiện lịch từ Outlook.com và Office 365. Tôi đã thấy có 2 lựa chọn:

1. Outlook REST API
2. Đồ thị Microsoft

Dường như chúng có giao diện tương tự. Tôi thấy rằng Outlook REST API có hỗ trợ cho các thông báo (webhooks), Microsoft đồ thị không? Vì vậy, một trong những lựa chọn, lợi thế/bất lợi là gì và tại sao có 2 api?

Answer 1

Để truy xuất và chỉnh sửa sự kiện lịch từ các điểm cuối API Outlook, Microsoft Graph API và API REST API hoạt động. Nếu bạn yêu cầu Webhooks cho một ứng dụng bạn đang có kế hoạch sử dụng trong sản xuất, thì bạn cần sử dụng điểm cuối API REST API v2.0. Chúng tôi có Webhooks có sẵn trong bản xem trước trên Microsoft Graph, và đang làm việc để GA chúng, vì vậy bạn có thể sử dụng chúng trong các ứng dụng sản xuất của bạn trong tương lai. Nếu bạn không cần Webhook cho ứng dụng của mình thì bạn có thể sử dụng Microsoft Graph v1.0. Cả hai điểm cuối API của Microsoft Graph và Outlook đều được hỗ trợ đầy đủ.

Bây giờ, tại sao có 2 điểm cuối. API REST API v1.0 của Outlook đã được ra mắt vào tháng 10 năm 2014 và chúng tôi đã cung cấp phiên bản v2.0 cải tiến vào tháng 11 năm 2015. Nó có tính năng Outlook mới nhất được hiển thị thông qua API. Microsoft Graph v1.0 là điểm cuối thuận tiện, chúng tôi đã khởi chạy vào tháng 11 năm 2015, để ứng dụng truy cập thông tin từ nhiều dịch vụ của Microsoft, ví dụ: Outlook, One Drive và Azure Active Directory. Trong thực tế, khi bạn thực hiện một yêu cầu tới điểm cuối Microsoft Graph v1.0 cho bất kỳ tính năng Outlook nào, yêu cầu sẽ được định tuyến đến điểm cuối API REST API v2.0 dưới các nắp. Vì vậy, các bộ API giống nhau theo thiết kế! Chúng tôi đang nỗ lực để đóng mọi khoảng trống giữa các điểm cuối API dịch vụ riêng lẻ (API Outlook REST, API OneDrive, API biểu đồ AAD, v.v.) và Đồ thị Microsoft, nhưng sẽ có một vùng đồng bằng nhỏ vì hai lý do.

1. Dịch vụ riêng lẻ có thể có các thực thể có cùng tên nhưng có ý nghĩa khác. Ví dụ, cả Outlook và OneDrive đều có "thư mục" nhưng chúng có nghĩa là những thứ khác nhau. Trong trường hợp này, chúng ta cần hợp lý hóa lược đồ API của Microsoft Graph để làm rõ cho bạn đối tượng nào bạn đang truy cập khi duyệt qua Microsoft Graph API. Thư mục đã có sẵn trong điểm cuối API Outlook v1.0 và chúng tôi đã đổi tên nó thành MailFolder trong điểm cuối API Outlook v2.0 và nó được hiển thị thông qua Microsoft Graph API v1.0. Vì vậy, bạn luôn có thể thấy một số tính năng hoặc API được hiển thị trong một điểm cuối dịch vụ riêng lẻ trong một thời gian trước khi tính năng hoặc API tương tự được hiển thị thông qua Microsoft Graph.
2. Một số khả năng ngang, ví dụ: Webhook có thể có sẵn trong bản xem trước hoặc GA trước đó trong điểm cuối dịch vụ trước khi có sẵn trong Microsoft Graph. Điều này là do Microsoft Graph API là một điểm cuối mới hơn so với các điểm cuối dịch vụ riêng lẻ. Theo thời gian, danh sách các khoảng trống này dự kiến ​​sẽ giảm xuống bằng không.

Đề xuất của chúng tôi là dành cho bạn sử dụng Microsoft Graph miễn là nó có các tính năng/API bạn cần trong sản xuất để hỗ trợ các ứng dụng sản xuất của bạn hoặc ít nhất trong Bản xem trước để hỗ trợ phát triển ứng dụng. Điều này giúp bạn dễ dàng hơn trong tương lai, để mở rộng chức năng ứng dụng của bạn yêu cầu quyền truy cập vào nhiều dịch vụ của Microsoft mà không thay đổi điểm cuối. Bạn có thể sử dụng các điểm cuối dịch vụ riêng lẻ như API REST của Outlook nếu bạn cần một tính năng chỉ có sẵn trong điểm cuối dịch vụ riêng lẻ, hoặc trong sản xuất (v2.0) hoặc dưới dạng bản xem trước (beta).