I would like to know difference between Office 365 REST API and Microsoft Graph, since we could find similar functionality for both of these.
https://msdn.microsoft.com/en-us/office/office365/howto/rest-api-overview
Following is the text from above link:
Office 365 API functionality is also available through Microsoft
Graph, a unified API that includes APIs from other Microsoft services
such as Outlook, OneDrive, OneNote, Planner, and Office Graph,
accessible through a single endpoint and with a single access token.
If there is no such difference, do you plan to deprecate any of these?
Thanks
Microsoft API is one endpoint solution to access the Office 365 services like mails, calendars and .etc. By using the graph api, no more obtaining separate tokens for different services or calling a different endpoint for each API.
Some features may be available on the individual service endpoints,
but not yet on Microsoft Graph. We are working hard to bridge these
gaps. If you require one of these features, you can use the individual
endpoint in the meantime. Check the release notes for details on the
Microsoft Graph features in preview and generally available.
For details, you could refer the document Choosing your API endpoint.
The Documentation state that Office 365 API functionality is also available through the Microsoft Graph, a unified API that includes APIs from other Microsoft services such as Outlook, OneDrive, OneNote, Planner, and Office Graph, accessible through a single endpoint and with a single access token. We recommend using the Microsoft Graph in your apps when possible.
Also see this answer it says
Our recommendation is for you to use Microsoft Graph as long as it has the features/APIs you need in production to support your production apps, or at least in Preview to support app development. This makes it easy for you, in the future, to expand your app functionality requiring access to multiple Microsoft services, without changing endpoints. You can use individual service endpoints such as Outlook REST API if you need a feature that is only available in the individual service endpoint, either in production (v2.0) or as preview (beta).
Related
Using the Outlook REST API, I want to make a browser extension (To-Do). I need graph api and the REST Task API. I make this application only for myself (maybe I will add it on github). Tell me, should I register an account as a commercial developer? Do I need to confirm for this application? Is it free? Where can I register the application? thank
I suggest you go through the Quick Start documentation, which will help you pick the appropriate platform and walk you through registering your Graph application. Also join the Office 365 Developer Program which will give you a free Office 365 developer subscription that you can use.
As I have understand - Live SDK has supporting 2 main features:
OneDrive and Microsoft account
Now with release OneDrive SDK all OneDrive features are coud be found in it.
But if you want to access Microsoft Account you still can use only Live SDK.
Seems that now we have 2 branches - Live SDK and OneDrive SDK.
One for account and another for files.
I am asking because sometimes it's not clearly written and looks like live SDk is depricated.
They are deprecated according to this:
The Live Connect APIs are deprecated. We recommend that you use the
Outlook REST APIs to build your solutions. This will extend your reach
to Outlook.com users and Office 365 enterprise customers. Although the
Live Connect APIs will be supported in Outlook.com for the short term,
existing Live Connect API solutions might stop working without
advanced notice. If your app is using IMAP with OAuth 2.0, it will
continue to work, but our REST APIs are the primary APIs for building
apps that connect to Outlook.com and Office 365. Read the article on
how you can take advantage of the Outlook REST APIs.
https://msdn.microsoft.com/en-us/library/hh243641.aspx
We are investigating solutions to integrate an Outlook user's calendar with our app and have looked into two Office 365 APIs - Unified (preview) and Exchange Online. So far, I've had issues trying to sign up for Exchange Online (either getting an Azure AD user to get Exchange Online, or to get an Exchange Online user to get Azure...I can't get both!) and it looks like Unified will be the standard API to use in the future. We've got things setup to use Unified, but are running into some server errors that do not seem like due to our configuration/code. (Oauth into Office 365 Unified (preview) - server error - non-retryable error has occurred)
To move forward with our project, is it recommended to continue researching Unified? Will Exchange Online eventually be deprecated and replaced by Unified?
Victor, there are no plans to deprecate the Outlook API's endpoint. The Unified API exists to simplify things if you are using multiple endpoints (SharePoint Online, Graph, etc). If calendaring is your main goal, the Outlook API is appropriate.
Also bear in mind that Unified is still in Preview and may have some issues.
If you have ever used the Flickr API, you'll be familiar with their API Explorer. It is an awesome tool, that allows you to view the documentation for each API method, and the killer feature, being the execution of that API method (with a form to populate any request parameters). It even picks up when you are logged in, and completes the authentication part on your behalf. Gowalla has a similar API Explorer that is also really good.
Are there are tools for WCF that will auto-generate such an API Explorer, free or commercial?
Currently, we use Fiddler to build the JSON requests, but I would like to publish these service contracts, and allow potential developers to play around with them via a web based API explorer.
I am aware of the WCF Web HTTP Service Help Page, which I am using (and is awesome), but it is the API Explorer part that I am interested in.
You may want to look at I/O Docs - an open-sourced interactive documentation system for RESTful web APIs that any API owner can use to deploy for their own documentation. It runs on Node.js and uses Redis as a data store.
https://github.com/mashery/iodocs
Example: developer.klout.com/iodocs, developer.rottentomatoes.com/iodocs
It uses JSON schema based files to define API endpoints, method and parameters. Based on these JSON files, it generates a client interface that developers can use to learn and explore your API. API calls can be executed directly from the documentation interface, producing formatted responses.
It's Open-sourced, so you can be assured of regular updates and improvements. In fact this past weekend, Brandon West from SendGrid (who use I/O docs to power their documentation), created and open sourced the UI to create/edit the JSON schema files for I/O Docs. So you don't have to manually create the JSON files anymore.
https://github.com/brandonmwest/iodoctor
Not exactly what you were looking for, but....
WCF provides something called the WCF Test Client, for this purpose.
If you install Visual Studio, you get it. For example, for VS2008, installed in the usual place, you can find the WCF Test Client (WcfTestClient.exe) in the following location:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\
Take a look at Apigee: http://apigee.com/
I'm looking for the client side and server side API for Lync 2010. But I found many API that can be able to develop. Anyone what are difference between all of them? Please help
Microsoft Lync Server 2010 SDK http://www.microsoft.com/downloads/en/details.aspx?FamilyID=58ccf6fd-31db-4f15-bafb-c5ef28afc5fc
Microsoft Unified Communications Managed API 3.0 Software Development
Kit
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4493BAAB-6214-4770-8CF9-69C813E8A9FA
Microsoft Unified Communications Client API SDK
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=82c468da-3294-4ca9-bbcc-d455cfd06af2
Lync 2010 SDK is the latest Client-side SDK for Lync 2010 (doesn't work against previous versions). Its a fully managed (i.e. .Net) API, and allows you to build apps that automate the running instance of Lync to perform tasks, e.g. display presence and start a conversation from your LoB app (Automation mode). It also allows you to build your own custom clients to completely replace the Lync UI (UI Supression mode).
Unified Communications Managed API 3.0 (UCMA) is the latest server-side SDK for Lync 2010 (doesn't work against previous versions) - its also a fully managed API, and allows you to build applications that register to Lync as endpoints. This is useful for building bots, for example, a stock ticker bot that IMs people when a stock price goes over a certain threshold. You can also build call routing and IVR (interactive voice response) apps with this, and it can use Windows Workflow Foundation to reduce the amount of code you have to write.
Lync Server 2010 SDK is another server-side SDK, but rather than creating endpoints as per UCMA, this allows you to write filters that plug in to a Front End server. A filter allows you to inspect SIP traffic as it passes through the server, so its useful for building e.g. archiving solutions.
Unified Communications Client API (UCCA) is a client side API that allows you to build custom endpoints - e.g. Lync client replacements. This is best avoided, as it is COM based, so you have a lot more code to write, and need to be very careful about memory leaks. Its recommended to use Lync SDK in UI Supression mode, instead of this API. One benefit it does have though, is it works against Communicator 2007, Communicator 2007 R2 and Lync.
If you're developing against Lync and no previous versions, then Lync SDK (client) and UCMA 3.0 (server) should give you what you need. Otherwise, this article here talks about the previous SDKs in a bit more detail
Edit: I've expanded on this in a blog post
The main difference for me between Unified Communications Client API and UCMA was that UCC supports digest auth and that's why it is possible to build sip/rtp client for linux based asterisk.