Spring Boot, decision to create DTO object separately both for REST and JPA -

i guess traditionally, 1 restful web service use 1 type of dto objects pojo/json conversion, , separate dto object database entity/pojo conversion?

spring boot should more opinionated , easier use, still use different dto object types json , database entity representation, or convert entity objects directly json?

let me share opinion.

at first, think question has nothing spring boot. spring boot provides fancy , lightweight way start application , allows build app in easier manner. still have rest controller there , point doesn't differ other type of application.

so you're asking whether makes sense maintain abstraction of json objects , converting them business logic entity objects , later on converting them once again database objects or enough maintain 2 levels , ditch json level.

i think answer "it depends".

first of all, in general trend simplification. maybe enough maintain 1 level of objects.

there lot of advantages of such approach:

• obviously less code maintain
• speed of development , testing (pojos should checked, converters should tested , forth)
• speed of execution - don't need waste cpu time on conversion. kind of obvious implication.
• less obvious: memory consumption. lets work big bulk of data returned dao. let's occupies 10mb of memory (just sake of example). if start convert, business entities, you'll spend yet 10mb , if json objects, again 10mb. point these objects may co-exist in memory simultaneously. of course gc take care of them if implemented right, different story.

however there 1 drawback of such simplification.

in 1 word call commitment

there 3 types of apis in application.

• the api you're committed @ level of web service - json structure. chances various clients (not necessary using jvm @ all) running against web service , consume data. expect provide json objects of given structure.

• the api of business. if business logic layer pretty complicated, have entire team develops logic. work @ level of apis between teams.

• the level of dao - same story business logic actually.

so now, happens if you, say, change api @ 1 level. mean levels broken?

example

lets say, don't maintain "json" level. in case, if change api @ level of business logic, json change automatically. rest frameworks happily convert object us, , chances user data.

another example

lets say, bl layer provides person entity looks this:

class person {       string firstname;       string lastname;       list<language> languages;    }     class language {      ...    } 

now, let's have ui consumes rest service provides list of persons upon request. if there 2 different pages in ui. 1 shows persons (in case doesn't make sense provide list of language, spoken person). in second page want full information.

so, you'll end exposing 2 web services or complicating existing 1 parameters (the more params have, less resembles rest :) ) maybe separation little here? don't know.

bottom line. long can live without such separation - it. can work quite big projects. , of course can work small or middle-sized projects.

if find struggling around fixes , feel such separation solve issues - separation.

hope helps understand implications , chose works