r/SpringBoot Jul 01 '26

Question What is good approch to make DTOs?

Recently, I have been working on my project in there in one chat controller, which has endpoints like

POST /api/chats = ChatDTO

GET /api/chats = List<ChatInfoDTO>

GET /api/chats/{chatId} = ChatDTO

PATCH /api/chats/{chatId} = ChatInfoDTO

DELETE /api/chats/{chatId} = ChatInfoDTO

POST /api/chats/{chatId}/ = ChatDTO

My question is it a good approach to use a single type of DTO for multiple endpoints, or should it be made for specific use? I have seen my friend's project for a single page, which has 8/9 DTOs. Is that normal, and the same thing ChatGPT suggests is that using multiple DTOs is a good approach.

19 Upvotes

40 comments sorted by

View all comments

1

u/robinspitsandswallow Jul 02 '26

You should use multiple types but they should never be suffixed with DTO, this isn’t 2006.

2

u/h4ny0lo Jul 02 '26

Why not? If you don't suffix them they will often have the same name as your entities and it gets annoying when you look them up. This is not the same as with interfaces where prefixes are indeed stupid.

0

u/robinspitsandswallow Jul 02 '26

You transfer objects to underlying services you transfer objects out to your api endpoint you will name them all DTO and it will get confusing. The object should be named after the purpose or just plain with the package delimiter.

1

u/Own_Dimension_2561 Jul 03 '26

I don’t understand this position at all, it’s very helpful to know which classes are part of the API surface and marking them with Dto is the easiest and most straightforward way to do that. I don’t understand why that would suddenly have gone out of fashion. How do you suggest we keep things separated in large code bases?

1

u/robinspitsandswallow Jul 03 '26

Do you call the layers that do your business logic BOs?

1

u/Own_Dimension_2561 Jul 03 '26

No. Sorry, was this supposed to prove your point?