API Design: Don’t expose your JPA entities in your REST API

Should you expose your entities in your REST API? or should you prefer to serialize and deserialize DTO classes?
That’s one of the most commonly asked questions when I’m talking to developers or when I’m coaching teams who are working on a new application.

In this video I will show you how you can create a robust API design by not exposing your entities in your API.

If you like this video, please give me your thumbs up and share it with your friends and co-workers.

Like my channel? Subscribe!

Join the free Member Library:

Want to connect with me?

#API #JPA #RestAPI

[ruixue]

00:28 reasons
00:50 create strong coupling
1:54 reduces the readability of your entity classes
1:57 slows down the application and makes it *hard to implement the true REST architecture*
4:21 handling the associations between your entities
4:59 in REST API, you handle this associations differently
5:04 the correct way would be to *provide a link for each association* 5:07 *Roy Fielding* decribed it as *HATEOAS* 5:10 it is *one of the essential parts of REST architecture*
6:52 example: bookstore app
09:06 wrap up

[cryptochamp]

Thank you so much for the explanation you provided, i cant express my thanks . I also went through many other videos of yours

[SuperGojeto]

Good video! I used to think exposing entities directly was so easy but later I did realise it causes tight coupling between api and persistence as well business logic. The extra code for DTO is really worth the time for enterprise and long maintanence projects. Mapstruct is really good library for DTO to Entity and vice versa. Our project did not use the DTO's initially because the deadline was too short to take wise decisions. I think it's because of the time constraints, many developers make hasty decisions. Given enough time, I think developers can code quality instead of delivery.

[Vanuatoo]

Great video as always. In case of API's I agree that you should use DTOs, but if you just expose REST back-end to one front-end which evolves over time I prefer to use Entities for POST, PUT, PATCH methods. It's better to have one place where you define all the bean validation constraints rather than to duplicate it in DTOs. with JAX-RS I just put Entity as a parameter and everything works fine. For GET methods in 99% cases I use DTOs.

[zehmhzg]

Thanks for video. Should we convert entity to dto in service layer or controller?

[nikkisingh]

Hello Mr theobon .I just want to how to do dynamic programming using hibernate jpa .I mean things like mapping entity at runtime, and other dynamic stuffs like changing schema at runtime.plz provide some information about this.i m very curious

[Blooffi]

I'm interested in using two different schemas with hibernate/jpa within the same database and your thoughts on that topic. Lets say the other schema is used for reading data which comes in from datawarehouse, and the other is used for business logic.

[bekhruzmakhmudoveducationb]

Good day. Please introduce which sequence the best to learn your lessons

[Lmfaorofl]

Thank you for the video, it made things much more clear!:)

I have a question: Is it better (performance & ease of use) to annotate many to many entities or split them up into three entities? For instance: an entity "event" has several "user" entities participating, likewise a "user" can participate on several events. Is it better to annotate set of users in event and set of events in users as many to many or make another entity called "participants" which binds a user to an event? Speaking from an ORM standpoint, more specifically hibernate. Do you have any thoughts on this?

[zickzack]

Spring Data Rest Repositories may help 😎

[swathihegde]

Can u explain with example how we can use dto and how we can expose only dto in api

[aelfric]

What's an example of when you might want to change your entity but not your API or vice versa? I would think it's more common that both would need to change as a result of some new or changed functional requirements.

[sousadax]

MapStruct os a great library that can be use in this cases.

Do you have or could record a video that shows a example of how to use Entity to DTO and DTO to Entity model? Thanks for the good work by the way. Nice videos!

[CottidaeSEA]

2:53 There is no reason why you couldn't do this at a later point in time if the necessity arrives, so I think this is a fairly weak argument overall. I think the JSON annotation argument is a far stronger one. Excessive annotation bloat is bad.
I think one of the most important reasons to use DTO is the increased amount of control you have over your data. You can represent it basically however you want to.

[JosifovGjorgi]

It's too much "what if" scenarios
Bad developers will create DTOs (just in case) and that case can happen in 10 years from now
Good developers will reuse POJO JPA entities and refactor the application when that "what if" case happens.
Now, you ask how to become good developer ?

You can look at the JDK classes and find patterns that can apply into your CRUD application
For example, you want Long to be represented as String, then you have toString method
Similar, you want class A to be represented as Json, but will only 2 fields from A, toJson method where you can nullify unnecessary fields.

Check JDK developers design the classes and view their presentation
At least they can show software that is Time-Tested Design