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.
Related
I am trying to configure a mailbox on Exchange Online to be used by our Deskpro ticketing system to manage several queues. The only way I could setup Deskpro to recognise different folders in the mailbox was to make the connection using EWS. MS said they would be deprecating EWS Basic Auth in October last year, does that mean my EWS connection via outlook.office365.com/EWS/Exchange.asmx is now authenticating through OAuth? It still works, I'm concerned MS will change something and it'll stop working.
I'd love to use the OAuth via Graph, but if I select that option in the Deskpro setup there's no way to identify individual folders for each queue to process meaning I'd have to have a separate mailbox for each queue requiring an Exchange Plan license for each!
Collin, yes there is an announcement made to deprecate EWS Basic auth (it was made quite some time earlier too) and move to modern auth/oAuth too - it will work for you. Also you know that no new investments are going to be made in EWS, so you wont get any new features. So keeping in that mind, you can use EWS modern auth/oAuth for a while, but i would recommend you to create plan to move to Microsoft Graph API - so that you can interact with all the existing features in EWS and connect with entire Microsoft Graph ecosystem's product/solutions as well.
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.
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.
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.
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