It's amazing that usage of CLR is no-no in SQL Server , but old-fashion OLE/COM integration is acceptable 😉
In general, my preference is not to have the database server connect to the API directly.
There are the obvious security reasons but there are also performance considerations.
My understanding is that CLR forces you to set the database to trustworthy, whereas old-fashion OLE/COM does not. I am trying to read up on the debate of enabling sp_OA and CLR, and they all read pretty much the same "security reasons" without an elaboration. What additional actions should be taken to shore up security if you enable Ole Automation?
I may be mistaken but I believe the trustworthy setting is only needed for certain types of assemblies. Ones that are not in the 'safe' list and ones that require external access of some sort. So to be fair, in this case I think it would be required considering what you are attempting to do.
One important distinction though is that trustworthy is a database setting whereas enabling sp_oa is a server level setting.
In a production environment this opens up a large attack vector.
I believe the process that is created is running as the account used to run SQL server. It inherently goes against the least privilege methodology.
From a performance standpoint, I don't like the idea using any of the scheduler threads to perform tasks outside of the database, especially tasks that can have an unknown amount of time associated with them. For example: downloading a large file.
OA also is known to have problems with memory management and so that's something else to deal with from a performance perspective.
It's not my intention to disparage the entire article though. It is great to see various ways to use the new JSON features.