Every action that is taken in the SonarQube / SonarCloud UI is driven by the Web API. There is nothing you can do in SonarQube / SonarCloud that you cannot do using the Web API.
We put a great deal of effort into the UI and UX of our products and sincerely think that most actions should be completed there. Especially when it comes to viewing analysis results, the UI is the best place to view up-to-date information with the right context. We think it is much better that you give access to others to view analysis data within our products, rather than craft some export.
And, we recognize that there are common administrative actions where using Web APIs to help with automation makes sense. There are also surely some interesting reports not available in the UI where you would need to export the data from SonarQube.
Hi Colin, i really like this explanation. I am not that much interested in frontend development and that made it hard for me to “grok” the easy way that Ann mentioned in some replies (how to eavesdrop on the Web API usage) For this, your howto helps a lot!
Concerning the below quoted paragraph (and combining it with your current survey question about “communitysm”) … maybe you might be able to find a way how to “channel” some energy concerning “common administrative actions”? I really would be looking forward to it! (because some lonely helpful threads really get easily lost in the sea of new postings).
Sadly, i was not able to find an easy solution … how to structure that? By tag? In its own “compartment” (e.g. smth like here)? I have no good suggestion to make
I hope this is on-topic (enough), but I’ve been using both the Web API documentation and the network activity in the UI to help me with building automations for SonarCloud. The Web API is especially useful as it let’s me generate a typed client by inspecting https://sonarcloud.io/api/webservices/list. (I have a go-sonarcloud client which, in turn, is used to build a Terraform provider for SonarCloud.)
My question is now: how should I deal with either deprecated endpoints or endpoints that are missing in the webservices/list? I figure for missing endpoints I could open a feature request at https://portal.productboard.com/sonarsource/1-sonarcloud/ , though it doesn’t feel like a feature request.
As an example of where I’m having problems: there are two important endpoints regarding permissions that have been marked deprecated for well over a year, but they still work. The API endpoints that replace them are not registered yet in the Web API Documentation, though they are in use by the UI. I’m still using the deprecated API endpoints, simply because I can generate the client code for them. I’d have to do manual work to add support for the new endpoints, and I kind of hate doing manual work .
Do you have any tips for a course of action here @Colin?