Is OData only for Javascripts in Dynamics CRM 13/15/16 ?
Depends. You can use OData in a variety of languages.
CRM provides two OData based services, check out Use Microsoft Dynamics 365 web services.
Web API
The Web API is new for Microsoft Dynamics 365 (online & on-premises)
and will provide parity with the Organization service. Compared to the
Organization service, the Web API provides better compatibility across
a wide variety of programming languages, platforms, and devices. The
Web API implements the OData (Open Data Protocol) v4.
The web api is new, and can be easily used outside of CRM in multiple languages and platforms.
Organization Data service
The Organization Data service, also sometimes known as the “OData” or
“REST” endpoint has also been available since Microsoft Dynamics CRM
2011. This service implemented the OData v2 standard. While this service will continue to be available as-is for years to come, we are
deprecating it with Microsoft Dynamics 365.
The organization data service is old (and deprecated), this was harder to use outside of CRM. Most of the time people used JavaScript to access it from within CRM.
Related
I am trying to compare the usage of EWS vs Outlook REST Apis for an application that needs to connect to an on-prem exchange server. From what I understand, Exchange 2016 onwards supports REST Apis which are leveraged by Graph APIs as well internally when it determines that the mailbox is on-prem.
My question is, is there any way my application directly use the REST APIs to talk to the on-prem exchange, similar to EWS, if I dont need to support cloud \ hybrid setups?
For example, can I use https://my-on-prem-exchnagehost/api/v2.0/me/messages to connect to and talk to my-on-prem-exchnagehost?
All resources about the Outlook REST APIs talk about a hybrid deployment but non about on-prem only setups. My intention is to use one implementation for both on-prem and cloud where just the API endpoints change in the application, example https://my-on-prem-exchnagehost/api/v2.0/me/messages for on-prem and https://graph.microsoft.com/api/v2.0/me/messages for cloud.
Yes, the REST APIs should be accessible on an on-prem server. Documentation here. Note that the Exchange REST API and the Graph APIs are different and it's not a drop-in replacement with the Graph's interface.
You should note that currently it is NOT supported to use the REST APIs in a pure on-premises environment. It may work (you can fire requests at the /Api endpoint and may get results), but if you hit any issues you are on your own. Until Microsoft announces support for on-premises (which at the time of posting has not happened; I am not aware of any plans to change this), then you should not use it.
My current project uses the EWS proxy API. I'd like to bring the code we utilize in EWS up to date and was thinking about importing the full EWS API. But I'm kind of wondering if Graph is a possible/better choice. We only have an on site exchange server, no hybrid or Office 365 stuff. We use EWS to grab emails from a specific folder and process them into a database. If Graph can handle on site only server tasks as good as or better than EWS would it be better to use Graph?
The Microsoft Graph does not support on-premises versions of Exchange. There is planned work to support hybrid scenarios, but if you are not connected to Azure AD/Office 365 you won't be able to use it when it is supported. You will have to continue to use EWS API.
I am interested in developing a Windows Forms application that periodically checks if my database has new entrances for a table that abstracts event scheduling.
If new events have been added to the database, my application should get those events and post them to the Office 365 Calendar.
I've been researching for a while and have not found a proper way to call Microsoft Graph API services from within a Windows Forms application.
Is it possible to do so?
There is a Microsoft Graph .Net Client Library available but you will first need to upgrade the version of .NET you're currently targeting to at least v4.5.
Alternatively, you can call into Microsoft Graph using either WebClient or HttpWebRequest. This will require you to construct all your calls and handle serialization/deserialization on your own however. You can find some additional details in this answer as well: HttpClient does not exist in .net 4.0: what can I do?
My guidance would be that unless you're very familiar with HTTP and Serialization, I would focus on upgrading your .NET target and use the SDK. Hand-crafting REST and OAUTH calls is typically not a very enjoyable experience.
I am working on Onenote integration for our application. I am new to onenote and microsoft graph. I don't understand the advantage of using graph api over rest api's provided by Onenote. Only authentication will be done through a common point for work/business and personal account that's the only difference.
Please help me in advantages of using graph api over individual application rest services.
check this - https://developer.microsoft.com/en-us/graph/docs
Microsoft Graph exposes multiple APIs from Office 365 and other Microsoft cloud services through a single endpoint: https://graph.microsoft.com. Microsoft Graph simplifies queries that would otherwise be more complex.
You can use Microsoft Graph to:
Access data from multiple Microsoft cloud services, including Azure Active Directory, Exchange Online as part of Office 365, SharePoint, OneDrive, OneNote, Planner and Microsoft Teams.
Navigate between entities and relationships.
Access intelligence and insights from the Microsoft cloud (for commercial users).
some of our customers have Quick book online and some of our customers have quick book offline. i want to develop Quick book integration for both in common way. is there any api there to develop integration for both in common
Already answered your question over here:
Intuit Developer Forums
Use IPP (Intuit Partner Platform)/IDS (Intuit Data Services).
The APIs for each are very, very similar, but not identical. It basically involves HTTP POSTing data to Intuit's servers. The data is then either relayed directly into QuickBooks Online, or held for later syncing against QuickBooks desktop versions (by default, Intuit handles the sync against QuickBooks desktop every 5 minutes).
Authentication against Intuit's servers is via OAuth, or via SAML (OAuth is easy, and the encouraged method of integration).
Documentation for that is here:
Intuit Partner Platform documentation
Note that as of April 2012, the Intuit Partner Platform APIs are only available to SaaS applications (i.e. if you're developing a one-off/custom application that you're not going to resell, then you can't use this set of APIs- in that case look at the Web Connector/SDK instead).
If you're using PHP, grab a nightly build of the PHP DevKit here for example code and libraries:
QuickBooks PHP DevKit
Additional info:
Intuit Data Services v2 has two separate but similar services one for QuickBooks Online and One for QuickBooks for Windows.
Intuit has released 2 SDKs one in Java and one in .Net which make programming against both easier. There is a common model for data that exists in both, and then you can extend to use data in Online or Desktop if needed.
.Net SDK for Intuit Data Services 2.0
Java SDK for Intuit Data Services 2.0
Next: Intuit Data Services v3 (One service to rule them all)
v3 brings QuicKBooks Online and QB for Windows under one service.
As with v2 Intuit will also provide java and .Net SDK support for the Service.