Share
ReportHi community!
I recently came up with the requirement of allowing some clients (I am supporting Dynamics 365 in my organization) to get some record data from my Dynamics 365 platform. They are currently using OData to fetch records from Dynamics, the cool thing is that any client no matter the type of program they are running can access the data by using OData queries. The problem is they can access more data than I wish (can be resolved by assigning security roles) and most importantly they are heavily dependent on changes made to entities and attributes.
Yes, meaning today they could be fetching records from the Contact entity, let's say specifically grabbing FirstName, LastName, SocialSecurityNumber and PhoneNumber attributes. If in the near future I decided to stop supporting the SocialSecurityNumber field and created a new one called "SocialSecurityNumber_Tokenized", I would have to let know my clients to modify their programs to now fetch the correct field. This implies changes to every client program consuming these records, which means code changes on their end, re-testing, developers getting mad, etc.. So this is when I came up with the idea of having an API in Azure which my clients can hit and obtain the records. Instead of having them write these ODataqueries, I would build an API that fetches these records. They would only have to hit the following method via HTTPS (sample) "fakeApi/api/myApi/GetContactData" which will return the records with attributes I choose to return in a nice JSON format response.
I see many benefits on implementing this solution, overall the most important one would be that any changes in my entities (database) would not affect my clients since any changes would be updated as well in my API, loosely couple integration will be achieved :).
What are your thoughts?
Change is the only constant...
*This post is locked for comments
All responses (
Answers (
30,188
