Is Microsoft preparing to add a “Solutions” class of API calls to Microsoft Graph?
A few days ago, Microsoft announced a breaking change to the beta endpoints of Microsoft Bookings Graph API.
By itself that’s not surprising: the beta endpoints can change multiple times during their journey to V1.
However, the change this time was unusual, in that it might be a indication of a future direction of travel for Microsoft Graph.
In the blog post, Microsoft announced that many (all?) of the Microsoft Booking Graph API endpoints were changing from “/beta/booking…” to “/beta/solutions/booking…”.
That’s right, there’s a new high-level branch of “solutions” under the /beta endpoint.
This is interesting because the term “solutions” doesn’t have anything to do with bookings, so it doesn’t make sense that it’s just a container for Microsoft Booking APIs. Instead, it feels more like a new grouping of a specific class of APIs, of which Microsoft Booking is one collection.
Microsoft Graph: home to your data, but also Microsoft services
Microsoft Graph has evolved since its beginnings and is now the home for many different things.
On the one hand, it’s where you can access your data that you (and your users) work with on Microsoft 365. Emails, OneDrive files, Microsoft Teams messages: all this is accessible via Microsoft Graph.
However, Graph also lets you work with a variety of other features and services as well, which don’t really fall into the same bucket of “your data”. Microsoft Bookings is a good example of that. Bookings is a service Microsoft is offering, and through Graph you can automate much of the administration of that service. The primary aim of the Bookings APIs isn’t so much to allow you to access data you’ve stored in Microsoft 365, it’s to let you use the service.
What I think we’re seeing here, is the first steps towards Microsoft moving all these “value-add services” into their own top-level section, called “/solutions”. It will take a while to fully complete: many of these services exist in the V1 namespace and so will need multiple-years of notice before the API endpoints can be updated. But, with the announcement last week it looks like Bookings have made the first steps on this journey.
Why?
Why make this change? Why is it necessary to group together an arbitrary collection of API endpoints that are more “service” than they are “data” into one place?
I don’t know. But here are a couple of ideas:
- it may be for back-end optimisation. The Microsoft Graph API definition is vast, and delivered by many different back-end services working together. It might be that having a top-level /solutions endpoint makes things easier on the back-end to manage.
- it may just simply to tidy things up and make the API simpler to navigate. I’m not sure I totally buy this one, as it’s a lot of effort to update V1 endpoints and I don’t think the juice is worth the squeeze here.
- Microsoft may be readying to start charging for access to these “value add” services via Microsoft Graph. Microsoft has been monetizing parts of Microsoft Graph for a while now and charging developers to access these services would be an opportunity to increase this revenue. Microsoft have consistently said that data in Microsoft Graph belongs to the customer and have always sought to provide a way to access that data via APIs without additional charge. At the same time though, they have been looking to charge developers where they feel they are adding additional value: such as allowing the data to be exported in bulk or in real-time, and so it is a natural progression for them to charge for services they are providing on top of basic access to data. I think this is probably the most likely option, although I think things get complicated where companies already pay for access to those services, either as a specific add-on, or as part of a bundle.
Or, there could be another reason entirely! We may just have to wait and see.
Written by Tom Morgan
Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.
Related posts:
Using the Microsoft Teams BETA Graph API calls? They may be about to break on you… 3 API calls going away soon
New in Microsoft Graph: API calls to get EVERYTHING a user sent in Chat, All Chats in Channels, and support for Apps in Chat
Microsoft will start charging for some Microsoft Graph Teams API calls starting July 5th 2022
Weekly Update 26 February 2024 – Graph API naming change, ACS & Open AI, sudo for Windows, IT Fundamentals
New in Graph – See and Manage Teams Devices!
Thanks for this blog post. I am fully with you and option c, i.e. this is the start of formally monetizing the services in MS Graph.
It may sound picky, but let’s dissect it: “My data” is the raw piece of info, that there is a meeting at date X with participant Y about Z.
However, offering a back end service to smartly suggest proper meeting dates (among other goodies) so the development of a booking web page becomes easy, has zero to do with “my data”.
I suspect, that MS wants to squeeze as much AI as possible everywhere, so all those “solutions” APIs will be ones, where there might be some AI mid layer to fancy up otherwise boring raw-data-access apis.