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.

About the author