API Design: Don’t expose your JPA entities in your REST API
HTML-код
- Опубликовано: 11 дек 2024
- 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!
➜ bit.ly/2cUsid8
Join the free Member Library:
goo.gl/dtyIIC
Read the accompanying post: thoughts-on-ja...
Want to connect with me?
Blog: www.thoughts-on...
Twitter: / thjanssen123
Facebook: / thoughtsonjava
Instagram: / thoughtsonjava
#API #JPA #RestAPI
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
You all probably dont care at all but does someone know a method to get back into an instagram account??
I was dumb lost my login password. I love any assistance you can offer me
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.
I realized this same thing. As I was returning an hierarchy of entities, I only needed the top level and not child objects. I needed control to be efficient and only load what was needed. Especially in different perspectives of loading data where you load a child and want to show the parent and in other cases you load the parent and want to show the child. @JSONIgnore allowed me to prevent looping and breaking the cycle, but I want complete control over my API and not have to dance around the rules of the JPA entities. While it is extra work, it simplifies the code in a way that is understandable.
Thank you so much for the explanation you provided , i cant express my thanks . I also went through many other videos of yours
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.
Good day. Please introduce which sequence the best to learn your lessons
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.
Spring Data Rest Repositories may help 😎
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
Thanks for video. Should we convert entity to dto in service layer or controller?
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.
That's OK, as long as both schemas contain different data and don't use any database triggers to keep them in sync.
In this video, I explained how to set the schema and table name for an entity: ruclips.net/video/1pa7M8SZV0M/видео.html
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.
You often need to ensure backward compatibility and, therefore, can't change your API.
In general, as soon as your client gets developed by a different team or you have more than 1 client application, you want to keep your API stable to allow independent releases.
Case: response renaming one field. You only chane dto and not persistence layer entity
Can u explain with example how we can use dto and how we can expose only dto in api
MapStruct os a great library that can be use in this cases.
Yes, that's a great choice if you want to use a mapping framework.
But it's often even better to use a constructor expression to select the DTOs from the database instead of entities (see thoughts-on-java.org/entities-dtos-use-projection/)
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!
Hi Anderson,
I'm explaining the different projections here: ruclips.net/video/jevTat_Jkgg/видео.html
In general, you should use DTOs for all read operations and entities only for write operations. If your write operation returns the written data to the client, then you need to decide if you map the entity to a DTO programmatically or if you fetch the DTO using a query. That highly depends on the amount of data and the overall use case.
@@Thorben-Janssen thanks for the excelent explanation!
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?
If you don't need to map any additional attributes on your association table, it's OK to model the many-to-many association to Sets on your entities. Just make sure to follow the general best practices for many-to-many associations: ruclips.net/video/808pWqjuhMo/видео.html
Loving it good stuff
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