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.
Related
SharePoint Online can be accessed either using SharePoint's own native REST API, or, using Microsoft Graph API. I have briefly explored both of the APIs and see differences in terms of the capability, for example, SharePoint API has function type method calls (GetByTitle()), whereas the Graph API seems to support identity based access, or, 'site path'. My opinion is that SharePoint makes it easy to access resources through the use of 'function' in URL, however, i am not sure if it is RESTful. It would be helpful to have your views on this aspect.
Given the two options (SharePoint & Graph) which is the recommended way forward, considering below criteria's:
Future proof - in terms of enhancement, support from Microsoft
Performance
Functionality coverage - considering current version of Graph API
Also, I couldn't find any Microsoft recommendations on this, if there is one kindly share the link.
Thanks.
I recommend Microsoft Graph API. I know it is a proxy to actual Sharepoint, OneNote, Planner, and etc API, but the way they are improving graph api day by day makes me think it is going to last for a good time. Let's say if you are writing an app that wants to connect with many Microsoft apps endpoints, having one class that handles all the graph api requests is enough instead of looking for specific apps endpoints.
Performance: I have been using Microsoft graph api for most of SharePoint related work and it works good and fast. I use Graph explorer to check out the graph if it actually works before implementing it in the app.
Functionality Coverage: Obviously graph is a proxy of a real api so it won't cover all the processes you need to do in SharePoint. For example, I had to create a Sharepoint Group which I could not find a way via graph api. But I assume as more people vote on those requests, the graph api is bringing those new possible proxy endpoints too. But again if your app is only working with Sharepoint then I believe I would stick to SharePoint API. In favor of Graph API, they also have something called delta query and subscription notification to see changes in the files and documents.
I was under the impression that the Graph API was meant to centralize things, make one endpoint to connect to all Sharepoint services via API. With that in mind, I wonder if we shouldn't be asking which is the better option but rather we should be asking when the so-called native option will be end of lifed. Graph is more future proof in the sense that this is the direction MS is taking. I can't speak to performance personally. As far as functionality, I can't imagine that Graph is functionally worse than previous iterations of SP. It might be functionally different. But it should expand API functionality.
What is the difference in using graph.microsoft & graph.windows. ? I am using graph.microsoft authentication to grab user information from AD for a Chatbot.
previously I was using graph.windows and since there was not enough information available with result string I used graph.microsoft. I wonder in future it brings an issue if I use it for production?
You will want to use Microsoft Graph (graph.microsoft) over Azure AD Graph (graph.windows). Both are still supported however Microsoft itself strongly recommends developers utilize the Microsoft Graph service.
You can read the original post from the Azure Graph team here explaining the differences between the two. It's from 2016 so things have changed since then.
This article, from November 2018, on Azure AD Graph, also recommends using Microsoft Graph.
Hope of help!
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.
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.
The reading I'm doing here seems to indicate that Microsoft Graph is for exposing Office 365 as an API.
The same link indicates its Office 365 and Azure AD. But you have to have an O365 account to interact with the graph.
That eliminates the use case of people who use only Azure AD, say for authentication and authorization in SaaS apps.
So, I've been asking about using Micrsoft Graph vs using Azure AD. Is it that as long as I'm not interested in the 0365 side of things that I should stick to the AD graph?
Update: Here's a blog from Microsoft on the matter. They said, "We strongly recommend that developers start using Microsoft Graph over Azure AD Graph, unless specific gaps prevent you from using Microsoft Graph right now."
Even if all you want to use are directory features, I would encourage you strongly to use Microsoft Graph. We are adding new directory features to Microsoft Graph that may not show up in AAD Graph and we are busy working to make sure that Microsoft Graph provides all the directory features that AAD Graph provides (and more).
You don't have to have an O365 subscription to use Microsoft Graph (just an AAD tenant) - it's just that Microsoft Graph exposes a lot of rich data that comes from Office 365, including calculated insights.
Please let me know if you are having any challenges with this.
Hope this helps,