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
Related
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).
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.
I need some guidelines here. I am creating an online booking system for my client that interfaces with QuickBooks on their internal network (desktop QuickBooks, not online).
Do I need to go the full "publish app" route? I do not wish to sell this app in the marketplace. This is merely a custom booking system designed and paid for by the client. It seems like I need to "publish" the app in the marketplace for them to be able to use it.
Are there ways around this?
Update 06/23/2015 - To connect to a desktop QuickBooks installation the SDK with the Web Connector is now the only recommended approach. Intuit is removing Intuit Partner Platform (IPP) integration to desktop QuickBooks.
For the SDK/Web Connector, you don't need to go through any publication process or anything like that. Just build the solution, and connector your client.
There's a pretty good overview of how the QuickBooks web connector works on our QuickBooks wiki.
The QuickBooks SDK download also includes a huge PDF with detailed documentation about how to implement SDK/Web Connector applications as well.
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.
Our company uses Quickbooks Online to track our books. When our application bills a customer, it would be nice to have that information recorded automatically in QB rather than logging in to QB Online to fill in the info.
Is there a way to accomplish this using Quickbook's APIs? The Intuit developer information is very confusing; it is mainly oriented towards extending the desktop version of Quickbooks or developing apps to publish in Intuit's app store.
Have you successfully created a web or other service-side app that was able to pull data to or from QB Online?
If you're building a one-off application, the QuickBooks Online qbXML gateway is the way to go. It's a pretty simple POST-your-XML-requests-over-HTTP sort of interface that gives you access to a large chunk (but not all) of the functionality within QuickBooks Online.
If you're building a SaaS application, then you should be looking at the Intuit Partner Platform instead. It sounds like you're building a one-off app for your company, so we'll focus on that:
If you look on my QuickBooks integration wiki there are some example qbXML requests to show you how to sign on, and how to POST qbXML requests to the QuickBooks servers.
You don't specify a language, but if you're using PHP, then try out my open-source QuickBooks PHP DevKit (look at docs/example_online_edition.php and docs/example_raw_online_edition.php in the .zip nightly builds).
You'll want to use the QuickBooks OSR for qbXML reference. The QuickBooks SDK also has 40+ pages specifically about QuickBooks Online Edition that you should probably review.
The Intuit Developer Forums are another good resource.