3
@Entity
class MyEntity {
   //some properties to be explosed to REST, some not
}

I have some database classes that I want to explose via REST using spring.

Is it advisable to create a DTO for each database class, copying over all properties needed to be exposed.

Because certainly some fields like the id should never be available via rest. But these fields can maybe be annotated accordingly so they are ignored during REST offer?

Is writing DTOs still advisable today if they just serve as plain data containers that get the fields copied over from DB?

membersound
  • 81,582
  • 193
  • 585
  • 1,120
  • 1
    DTOs are useful as they hide the entity structure from outside world. Unless its a prototype you are building, prefer DTOs over exposing entities directly – Wand Maker Jul 15 '15 at 18:56

1 Answers1

5

Some points I can think while deciding:

Arguments against common model for persistence & web service

  1. In many applications the rest services are written to provide you a fully constructed object & not really a normalized view of the data. For example your rest service may return an Employee object with a Department object, wheras your db model just has a deparment id
  2. Modifications in 1 model do not affect the other. For example you decide to change a String in the persistence model to an integer, you may still be ok with keeping it as a string in your rest service
  3. You may have attributes in the rest model which make no sense to be on the persistence model or vice versa
  4. If you are distributing your model jar (like a client API) then it may end up with a dependency on your persistence framework which your clients may not want/support.

Arguments supporting common model for persistence & web service

  1. Avoid copying/cloning data for every interaction
  2. Avoid duplicate maintenance or possible issues when an attribute is added in 1 model and forgotten in another

In my experience if you are creating services exclusively to be consumed by your own application (like a UI) and have tight control on those services, you might get away with using a common model

However if the rest API is intended for broader use and for longevity I would go with separate models. You can use spring's beanutils to ease the conversion of models from one format to other. See example here

Community
  • 1
  • 1
6ton
  • 4,174
  • 1
  • 22
  • 37
  • Thanks for your detailed points. Could you just add some hints what you mean with using "spring beanutils to ease the conversion"? – membersound Jul 15 '15 at 22:10
  • 1
    @membersound added a link with example – 6ton Jul 16 '15 at 00:11
  • Also take into account that integrating HATEOAS with entities is complex if you use a common model fro the persistent and the REST layers (how can you decorate the entities with the HATEOAS links?). Likewise if you follow a HAP approach, how can you decorate the entities with (e.g.) an "_embedded" property? Last but not least validation annotation shoud be duplicated if you use different models for the persistent and the REST layers. – Mike Argyriou Mar 06 '16 at 11:38