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.
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.
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.
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.
I am creating iOS application that needs to interact with RESTful API (which will be going to make).
The problem is I have no knowledge in the realm and would like to ask for some helps. (I tried to learn this for few days but as I study more, I get so confused...)
My company has a server that is running with Windows. What is the process of deploying APIs there and use it as data storage as well.
My company has Microsoft 365 license so that I have access to SharePoint. I've read there is SharePoint APIs, so it will be nice to integrate with my app. But more I study about it, I've observed AzureAD. Is it something that I must to have in order to utilize MS SharePoint APIs?
I know it is very broad question but I really appreciate for anyone who provides with helps. Thank you
Yes you will need Azure AD to interact with the sharepoint api, using the oAuth authentication by registering the app into the Azure AD and giving the Sharepoint Management online permissions that are required for you to do the operations that you want.
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.