In order to position CRM as a platform for application development, its web services need to be easily accessed by a wide array of consumers while still exposing the majority of the functionality the system provides. The new Web API solves both of these problems, and in today’s blog, we’ll show you how to get started with the CRM 2016 Web API.
Prior to CRM 2016, developers were able to access the SOAP based endpoint and have full access to all the APIs CRM made available, but the cost was getting authenticated and working with it from non-.NET applications was challenging. The other alternative was to use the REST based endpoint, which was much friendlier to use outside of .NET, but that only provided a small subset of functionality. Web API combines the two by providing an endpoint that’s easy to use regardless of the language and still provides all (with a few limitations currently in v1) the functionality to get things done.
2. Bound and Unbound Functions – Operations that typically retrieve data that previously required using the Execute message.
3. Bound, Unbound, and Custom Actions – Operations that typically make modifications to the system that previously required using the Execute message.
- Bound Action = Tied to a specific entity – system defined
- Unbound Action = Not tied to a specific entity – system defined
- Custom Action = Can be bound or unbound – user defined
4. Execute Saved Queries – Retrieve data from system or user defined views.
5. Execute FetchXML – Retrieve data based on a FetchXML query.
6. Batch Operations – Support for ExecuteMutliple to send multiple operations in a single request to the server.
7. Impersonation – Make requests under the context of a different user.
8. Optimistic Concurrency – Check for and handle situations where data on the server might have been modified since it was last retrieved.
9. Discovery Service – Access information about all the instances the user belongs to.
In order to get started when coming from outside CRM, you’ll first need to register an application with Azure/On-premises Active Directory. This process associates the directory provider (AD) with the application (CRM) and provides another level of security by providing an interface to control permissions to specific applications. The take away from this step is a client ID that will need to be referenced in any application trying to authenticate against Azure/Active Directory to CRM.
Getting authenticated is a breeze thanks to Microsoft’s Azure Active Directory Authentication Libraries (ADAL for short). So long as you use a valid client ID, in most cases you’ll be able to authenticate via interactive mode using the Office 365/AD FS login page or using a fixed set of CRM credentials for integration scenarios. The beauty of using OAuth for authentication is that it allows you to connect from virtually any modern programming language capable of making an HTTP request, the ADAL libraries just simplify the process down to a few lines of code.
The authentication process returns a token which needs to be included in the header of future requests, but once you have the token you’re ready to start working with CRM functionality. On a side note, this token will allow you to consume both the new 2016 Web API and 2011 REST endpoints. You can check out the official CRM Web API documentation from the CRM 2016 SDK here.