Request and Response DTO naming convention

Hi all,

Just wanted to get some feedback on best practices for naming request and response DTOs.

If we have a ‘Tasks’ service with Get tasks and get task by criteria etc. What is the recommended approach to naming request and response DTOs?

Some examples seem to be
TaskService, Task [request dto] with Get, Put, Post methods and List<Tasks> as the response.

Others seem to be
TaskService, GetTasks [request dto], SearchTasks [request dto] and a TaskResponse [response dto with List<Tasks> and ResponseStatus properties].

I would really appreciate your thoughts on which approach would be better and why?

Thanks,
Leeny

Please read these docs below on designing services:

It already covers a number of your questions, e.g. the docs go over keeping a consistent nomenclature so your “Get” Services are kept different from your “Search” Services which filter results from different criteria.

My preferred approach is to name the Request DTO after the name of your Service and use a *Response suffix for the name of the Response DTO. You can share the same Response DTO or return naked response like List<Task> but I prefer to have an explicit Response DTO for each Service as they can evolve independently without breaking changes to existing clients. It’s also clear as to which Response DTO is for which Service/Request DTO.

So for this case my Services would look like:

class GetTasks : IReturm<GetTasksResponse> { ... }
class GetTasksResponse { ... }

class SearchTasks : IReturm<SearchTasksResponse> { ... }
class SearchTasksResponse { ... }

class TaskServices : Service
{
   public object Get(GetTasks request) => new GetTasksResponse { .. }

   public object Get(SearchTasks request) => new SearchTasksResponse { .. }
}

Also checkout AutoQuery if you haven’t already as it lets you define Query/Search Services with just a Request DTO, saving you the effort from implementing it as well an instant UI to query AutoQuery Services if you need it.

Thank you so much Demis.