Out of interest, do you think your recent experiences with SharePoint were because Microsoft decided to unify pretty much all of their services behind the common Microsoft Graph API? SharePoint used to suffer from having multiple different overlapping styles of APIs depending on what API style was fashionable at the time that feature was developed - which could make development a nightmare... (OK, an even bigger nightmare).
I sort of like ODATA on the client end of things. It's an absolute nightmare on the server side, at least with .NET, but for clients it's usually fairly easy to consume. This is true for every part of the Microsoft Graph API that I've worked with except for the SharePoint part. Which for whatever reason works differently when you query things. It's sort of hard for me to answer though. I've spent quite a lot of time in enterprise organisations, and I've integrated with basically everything, and it's almost all bad in one way or another. On that scale I think the Microsoft Graph API in general is a 8/10 maybe even a 9/10, but the SharePoint parts of it are at most a 5/10.
I'm not 100% sure this is the fault of the API, if it's because of SharePoints indexation, if it's because of the 3rd party meta-data indexation that we buy for our document library or if it's because of how terrible our own architecture for the data flow is. But I've had to build a lot of redundancy and caching into the terrible piece of gaffa tape which is our integration, because SharePoint won't give me every document everytime that I ask for them.
So a bad experience? But at least it's not FTP (yes not sftp) pulling different file formats from 9000 solarplant inverters bad.
