My current project uses the EWS proxy API. I'd like to bring the code we utilize in EWS up to date and was thinking about importing the full EWS API. But I'm kind of wondering if Graph is a possible/better choice. We only have an on site exchange server, no hybrid or Office 365 stuff. We use EWS to grab emails from a specific folder and process them into a database. If Graph can handle on site only server tasks as good as or better than EWS would it be better to use Graph?
The Microsoft Graph does not support on-premises versions of Exchange. There is planned work to support hybrid scenarios, but if you are not connected to Azure AD/Office 365 you won't be able to use it when it is supported. You will have to continue to use EWS API.
Related
we currently Migrating EWS connections in our application (EWS support fo Office/Outlook 365 will be outdated soon/this fall) for all our customers using Outlook as port of Office 365 using msgraph-sdk-dotnet.
EWS offered EventType.Moved for subscritions in order to deteced mails which has been moved to observerd mail forder. Some of our uses cases are based heavily on this feature.
So we are wondering what's the equivalent of EventType.Moved is in msgraph.
subscription resource does only offer the following: changeType-s created, updated and/or deleted .
How should we map/port EventType.Moved from EWS to msgraph?
Delta requests cannot be filtered for moved mails either or this there a hidden feature or a neat trick in order to detect if a mail has been moved into an folder?
Any hints for this porting issue would be really great!
Thx
I am trying to compare the usage of EWS vs Outlook REST Apis for an application that needs to connect to an on-prem exchange server. From what I understand, Exchange 2016 onwards supports REST Apis which are leveraged by Graph APIs as well internally when it determines that the mailbox is on-prem.
My question is, is there any way my application directly use the REST APIs to talk to the on-prem exchange, similar to EWS, if I dont need to support cloud \ hybrid setups?
For example, can I use https://my-on-prem-exchnagehost/api/v2.0/me/messages to connect to and talk to my-on-prem-exchnagehost?
All resources about the Outlook REST APIs talk about a hybrid deployment but non about on-prem only setups. My intention is to use one implementation for both on-prem and cloud where just the API endpoints change in the application, example https://my-on-prem-exchnagehost/api/v2.0/me/messages for on-prem and https://graph.microsoft.com/api/v2.0/me/messages for cloud.
Yes, the REST APIs should be accessible on an on-prem server. Documentation here. Note that the Exchange REST API and the Graph APIs are different and it's not a drop-in replacement with the Graph's interface.
You should note that currently it is NOT supported to use the REST APIs in a pure on-premises environment. It may work (you can fire requests at the /Api endpoint and may get results), but if you hit any issues you are on your own. Until Microsoft announces support for on-premises (which at the time of posting has not happened; I am not aware of any plans to change this), then you should not use it.
I am building a web application that needs to fetch all tasks from an organization that uses Outlook Task. Can this be done with Microsoft Graph or Office 365 REST API?
I haven't found any calls in the documentation of either services that would do something similar to that: https://outlook.office.com/api/v2.0/tenant/tasks
Should I find another approach or is it something that is doable?
Outlook Tasks is available in Preview on Microsoft Graph today:
GET /users/{id|userPrincipalName}/outlook/tasks (Graph Explorer example)
I'm afraid I don't have an ETA for when this will be generally available at the moment. According to the Change Log this functionality was added in April so it is still a somewhat recent addition.
This functionality is also available as part of the Office 365 REST API.
If you're looking for something production ready today, you may need to use this API instead. If possible, I would suggest waiting for Graph. Graph is where all future engineering energy will be focused and is the best long-term integration play.
I am working on Onenote integration for our application. I am new to onenote and microsoft graph. I don't understand the advantage of using graph api over rest api's provided by Onenote. Only authentication will be done through a common point for work/business and personal account that's the only difference.
Please help me in advantages of using graph api over individual application rest services.
check this - https://developer.microsoft.com/en-us/graph/docs
Microsoft Graph exposes multiple APIs from Office 365 and other Microsoft cloud services through a single endpoint: https://graph.microsoft.com. Microsoft Graph simplifies queries that would otherwise be more complex.
You can use Microsoft Graph to:
Access data from multiple Microsoft cloud services, including Azure Active Directory, Exchange Online as part of Office 365, SharePoint, OneDrive, OneNote, Planner and Microsoft Teams.
Navigate between entities and relationships.
Access intelligence and insights from the Microsoft cloud (for commercial users).
Is there any difference between what one can get from
https://graph.windows.net vs https://graph.microsoft.com?
It seems that there's different versions for one, .net is under version 1.6 and .com under 1.0.
They both seem to work with the v2.0 auth scopes, but do they work the same way?
Thanks to anyone that can shed some light!
Using Microsoft Graph (https://graph.microsoft.com) you can access the data that is exposed in the Azure AD graph API (https://graph.windows.net) and, in addition to that, access data from services like Outlook/Exchange, OneDrive, SharePoint, OneNote, Planner and more (for both consumer and commercial).
The recommendation is to use Microsoft Graph API. That said, there is still a small percentage of functionality that is only available in the Azure AD Graph and we are working hard to close the gap.