I'm trying to use delta queries on my AD and it works perfectly when I try them out through Graph Explorer, but doesn't work at all with my app, I'm getting this:
message=Invalid request. Delta query is not supported by this resource.
My app is an 'old' app, meaning it was registered in Azure to work with old WAAD graph api. Is this why it's not working? Or could this be because of my app lacking some permission that Graph Explorer requires? I can read 'users' without any issues, it's only delta queries I'm having issues with.
The application requests the following permissions:
Access the directory as the signed-in user
Read all users' basic profiles
Sign in and read user profile
Token requests are managed by the library, it's asking for the following scopes: openid profile
If you're using Azure AD Graph then you cannot use /delta queries. AAD Graph API and Microsoft Graph API are entirely distinct APIs. Calls to one are not interchangeable with the other.
If you're looking to leverage /delta you'll have to refactor your application to use Microsoft Graph API.
Had to spend the whole day on this issue, here's what was going on. I was adding this HTTP header to the request (per some sample documentation):
Prefer: outlook.timezone="E. Europe Standard Time"
And that's what was breaking the delta queries request, as soon as I've removed the header - request returned delta data instead of an error. I wish the error could be more descriptive, I wouldn't have to spend so much time figuring this out.
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.
Whenever I query the Teams endpoint in Microsoft Graph:
GET https://graph.microsoft.com/beta/teams/{id}
I get the following error:
AccessDenied - Failed to execute Skype backend request GetThreadRequest.
The permissions are set according to the documentation. (Group.Read.All - delegated permission)
Querying https://graph.microsoft.com/beta/groups/{id} is working while with the same access token https://graph.microsoft.com/beta/teams/{id} isn't.
I tried it with my own application and in the Graph Explorer. Both ways didnt't work for me. However using Graph Explorer with the sample account is working. Is there maybe another permission needed which is not yet documented?
Currently it's a requirement that the person using the Graph APIs (and the PowerShell cmdlets that use them under the covers) must be a member of the team whose information they are trying to retrieve. This is the second-most popular ask for users of our cmdlets, and we are close to resolving it. We expect this to be fixed by the end of September 2018, with write APIs/commands coming a few weeks later than read APIs/commands.
Since Graph is a self-documenting language, I wanted to use this to my advantage and write PowerShell functions to automatically generate cmdlets based on metadata. I've got a lot of this complete, but am having problems figuring out scopes. Is there a way to find scopes? It's not stored in the metadata and the documentation doesn't have scopes listed for everything (for instance, nothing in Excel has scopes listed).
The Graph Explorer seems to request correct permissions, so that has access to this list somewhere.
It depends on which API you are looking for.
Scopes for Azure AD Graph API is at https://msdn.microsoft.com/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes.
There is a huge list for different parts of the Microsoft Graph API at https://developer.microsoft.com/en-us/graph/docs/authorization/permission_scopes.
When you first sign in to Graph Explorer, you give it these permissions:
Based on the descriptions and the link above you can figure out what the scope name is for each of the items in the list. (E.g. the first one is Mail.ReadWrite).
When you create an application in Azure AD, you configure which applications it needs access to, and what access it needs. That results in the list which the user grants access to on first signin.
Office 365 administration center allows to create organizational contacts which are shared with all users in organization.
In MS Graph documentation API of this functionality is badly documented and located in BETA section. Moreover, there is no command to create such a contact: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/orgcontact
It looks like in Graph this functionality was not implemented. Using typical POST request to the /beta/contacts ends with an error response in Json structure: Unsupported resource type 'Contact' for operation 'Create'.
Note 1: I don't have any user logged in. My application uses service/daemon authentication.
Is there any other way to create organizational contact?
At this time, creating new orgContact objects isn't supported by the Graph API. You also cannot create organizational contacts with the Azure AD Graph API. For more information about organizational contacts, including how they are created in your tenant, see the Contact Entity documentation.
Organization Contacts are documented in the beta section because this API is in fact still in beta. I'm sorry you ran into issues here but with any beta endpoint there is always likelihood of missing/broken features and sparse documentation. There is also a substantial likelihood of breaking changes being rolled out to beta endpoints. As such, we do not recommend using them in production scenarios.
https://graph.microsoft.io/en-us/ seems to be built on top of the Azure AD graph - https://graph.windows.net/
I haven't found a lot of how graph.microsoft.io was built, but it seems like it is a superset of the original Azure AD API, together with the stuff to access data from Office 365 through the graph.
What stands out to me is that either they would have passed through queries from graph.microsoft.io to graph.windows.net or they would have rebuilt it all from scratch. So, I'm trying to understand how to build my own such graph. I will use Azure AD, which will enable my authentication and authorization. It will give me a graph of the users in my organization. But for custom applications that also use Azure AD for login, I would like them to be available via the graph, like how the Office 365 apps are available via the graph.microsoft.io site.
So far, to implement something similar, it seems like I can use the core Azure AD graph for a specific set of user data, and for apps that use the Azure AD instance that I provide, I can require them to implement an Odata endpoint which describes how their own data can be accessed.
Is this a good approach?
It's certainly pretty much exactly what we do, so who am I to argue. However, rather than going to Azure AD directly for the graph of users in your org, I'd encourage you to go to MS Graph for that data, as we'll be looking to add richness and functionality there rather than in the underlying AAD Graph as time marches on, and also it will enable you to link across easily to other Office apps of course.
Over time, we'd like you not to have to do this, but rather to bring your own apps' data into the Microsoft Graph in some fashion, but we are a ways away from having that facility available.