There is a common pattern that is used in .NET APIs where anything that returns a Task has the suffix Async.
Task<Result> GetResultAsync();
However, in reality this is just another form of Hungarian Notation. "But Microsoft do it in the BCL" you may say. And of course you are right. Buts lets be clear – they had to as they already had synchronous versions of the APIs from previous versions of .NET.
WebResponse GetResponse(); Task<WebResponse> GetResponseAsync();
So the Async suffix really came from expediency rather than a proposed standard pattern. In fact, where the API already support the Event Async Pattern (EAP) there already existed a version of the API with an Async suffix so they had to use TaskAsync to disambiguate.
Task<byte[]> DownloadDataTaskAsync();
If you have to support both a sync and async version of an API then maybe still use it – or rather, to encourage async interaction suffix the synchronous version with a Sync suffix as in NodeJS APIs.
But most APIs should be either inherently sync or async and in that case leave off the suffix and just return the appropriate type.