This Microsoft's documentation page: https://developer.microsoft.com/en-us/graph/docs/concepts/deployments indicates that support for Delta queries against Microsoft Graph API varies across different resources on each national cloud deployment.
I would like to know exactly which deployments support Delta queries against Microsoft Graph API, but I couldn't find any documentation about this.
As you discovered, we don't currently document which clouds support delta query.
If you're willing to do a bit of investigating, I can show you a trick to see not only which clouds support delta query but also which specific endpoints support delta query.
You can send metadata requests to each cloud like https://microsoftgraph.chinacloudapi.cn/v1.0/$metadata or https://graph.microsoft.com/v1.0/$metadata. Note that these requests don't require an access token in the header so you can actually just open these links in your browser.
Search this XML for delta and you'll see our delta function definitions. For example, the following says that the user collection (GET /users) supports delta query.
This one means that groups supports delta query.
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.
I'm trying to query the Global Address List using Microsoft Graph. I've worked with and adapted the sample code from https://github.com/microsoftgraph/console-csharp-snippets-sample.git -- however, I'm still having trouble. I've seen this article -- Global Address List Graph API -- which indicates I need to use the "/contacts" endpoint. However, I don't see how this helps me when I'm using the Microsoft.Graph library. Is there some method or collection within the Microsoft.Graph library that will allow me to read the GAL?
"GAL" is a MAPI concept that doesn't really apply to Graph. With Graph, you just read the users or contacts in your company's Active Directory. By combining both lists, you come close to what you'd see in the GAL in a MAPI client.
To do that, you would list users as doc'ed here: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/user_list
Using the library, I believe this will get you started:
client.Users.Request().GetAsync();
For contacts, it's a lot trickier with the Graph library. Organizational contacts are only supported in the beta version of Microsoft Graph, which the client library doesn't support unfortunately. (See this issue for info). Michael Mainer did a write up of how you can generate your own beta version of the library if you're interested.
The info on querying organizational contacts is found here: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/orgcontact.
As of late 2021, doesn't appear to be an easy "Export Global Address List" API from Microsoft. There appear to be manual methods (e.g. using the Exchange Admin interface) but nothing programmatic.
Below is broad strokes exercise for creating an approximation (that may be sufficient for your needs). A more accurate exercise may be to export the GAL from a official client (e.g. Outlook/Outlook Web/Exchange Admin interface). Its possible that in some cases the GAL is user specific which may make GAL export concept significantly more involved.
GAL export exercise:
APIs:
MS Graph API (available via HTTP, e.g. GET/POST)
Users
Groups
Some of the above only allowed certain properties accessible by individual record query - I needed to get the whole list then iterate through each record one by one to get all needed properties.
Exchange Powershell (available via Powershell)
Get Mailbox (for flags not exposed by Graph/Users)
Get-DistributionGroup (for flags not exposed by Graph/Groups)
Azure Functions can be used to run these queries serverless/"API-ified". Azure App Registration can be used as OAuth app that can be granted the permissions to access the above. Microsoft Graph Explorer is handy for testing Graph requests.
Put it together:
Smash the datasets together and then filter out on fields. Some flags are:
hideFromAddressLists
hideFromOutlookClients
HiddenFromAddressListsEnabled
showInAddressList,
some conditions you have to manually check for, e.g.
if no provisioned plans (i.e. unlicensed)
if no email address
etc.
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.
I need some conceptual understanding of Neo4j REST api's usage. I went through the tutorial of neo4j RESt api and got some idea. So is it like these REST api's are used only to CREATE nodes and Relationships and also to fetch data from the neo4j graph database? So can you give me one example/scenario where and how these neo4j REST api's are used?
Thanks,
Shree
Historically the very granular REST API calls for e.g. creating nodes, setting properties were there before Cypher was established. Cypher is a way more concise and compact way to query and modify the graph compared to the granular REST calls. These days you typically use Cypher over the transactional http endpoint.
For some usage examples refer to the manual as well.
what Tin Can API can do other than storing the state of the agent and how can we retrieve the publicly stored statements from Tin Can API
Thanks in advance
You can do a lot with the Tin Can API (Experience API). The point of the xAPI is to store user experiences, anything from I completed a course to I started watching a video. I've seen or worked on things as simple as using the xAPI to send SCORM tracking to an LRS, to support mobile, tracking sensor data from field exercises, to storing information collected in games and simulations. And the Experience API gives you the ability, like you said, to get data back out in a standard way, to support reporting and evaluation of data.
There are groups working with the Experience API to do interesting things. https://groups.google.com/a/adlnet.gov/forum/#!forum/xapi-design
There is also a spec working group forum where you can get more resources and answers: https://groups.google.com/a/adlnet.gov/forum/#!forum/xapi-spec
There are also resources and articles talking about what you can do with the Experience API. http://www.adlnet.gov/tla/experience-api/
and http://en.wikipedia.org/wiki/Tin_Can_API
There are some open source projects on ADL's GitHub page that also show how you can use the Experience API. https://github.com/adlnet
For sending and retrieving info from an LRS in web browsers there's a JavaScript library: https://github.com/adlnet/xAPIWrapper .. it's been built and minified..you can just include the xapiwrapper.min.js in your page and use the readme examples to get started.
For reporting and querying data you can look at the new project: https://github.com/adlnet/xAPI-Dashboard
There's a starting Java library to make talking to an LRS easier in Java, which could be used for regular Java apps or for Android apps: https://github.com/adlnet/jxapi
They're also starting a JQuery Mobile Plugin: https://github.com/adlnet/xapi-jqm
And even an example of using the Experience API with MedBiquitous and Common Core competencies to identify learner's progress toward becoming competent in some aspect: https://github.com/adlnet/xci
As for your question about getting statements from an LRS, you would just do a GET request to the statements endpoint. The spec currently says that requests must include the Experience API version header: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#62-api-versioning . And you will probably need to authenticate as a client using the LRS. This is generally done by registering on the LRS and getting some sort of credentials. This will vary based on the LRS you use, but they all have instructions on how to use and send the credentials. https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#64-security
ADL's hosted example LRS opened up the GET statements endpoint so that people new to the Experience API could hit it and see statements without needing to figure out the request rules: https://lrs.adlnet.gov/xapi/statements