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.
Suddenly, it’s very clear from the Request URL which API was called. The Payload tab and Preview/Response tabs make it clear what query parameters are used and what the response was.
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
great post! This is exactly what I have been using for years to get in deeper with many tools.
I remember with a shudder the crappy browser tools of IE 11, but these days press F12 and start diving
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?
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.
For this, your howto helps a lot!
.