Is there a way to generate spring rest crontroller for a business flow.
I want to generate CRUD services for given database object.For example, "employee_mst" , generate CRUD services code automatically.This is similar to what we used to have in hibernate or what we have in loopback.io for node. Appreciate any help around it.
I found a link that may answer your question: https://docs.spring.io/spring-data/rest/docs/current/reference/html/.
This text explains that Spring Data REST generates REST interfaces from Spring Data repositories.
I intend to try this but did not do so yet.
EDIT: I saw in my example application that Spring Data REST did what I expected. I could request all entities in my Spring Data repository using a HTTP request. The returned JSON contained also discovery information. You may prefer writing your own controller to have more control on what information is returned.
Related
Is form attibute binding vulnerable to A8:2017-Insecure Deserialization
I was testing Spring boot form submission for my internal project when I came across -
OWASP TOP 10 A8:2017-Insecure Deserialization
As per my current project,
I am binding the form parameter and getting a SearchPOJO at my controller
using #RequestBody
I have the following doubts:-
Is it safe to pass the parameters as Spring may create the POJO, serialize it and then send it over to network, hence I am vulnerable to A8:2017-Insecure Deserialization?
Does Spring boot perform the same process in any different way?
If there is a vulnerability, then will sending form data using #RequestParam/#PathVariable shall solve the issue?
As of now we are using Thymleaf in Frontend We are also planing to
switch to React Frontend in the coming months.
OWASP TOP 10 A8.2017
I would be highly obliged if someone can clear my doubts.
I do REST API on Spring. Took a course in Spring Data Hibernate and found that it made the REST API the most time-consuming way.
When I added a new entity to the domain, I went through the following chain of objects:
Entity - domain object
DTO - for transmitting/receiving an object to/from a client
Mapper - to convert between Entity and DTO
Repository - for interacting with the database
RestController - for processing API requests
Service - service class for the object
The approximate chain of my actions was as follows:
RestController processes requests - receives DTO from the client (in case of creation of a new object)
Mapper in controller converts DTO to Entity
Service is called
Service accesses the Repository
Repository returns the result of execution (created by Entity)
Service returns Entity is created in RestController
RestController returns to the client an object of type ResponseEntity, where I put the body and response code.
As you can see a large chain of actions and a large number of objects.
But then I found out that if you use Spring Data REST, all this doesn't need all the API supplied by Spring from the box. In general, you only need to create an Entity and Repository.
It turns out that for typical CRUD-type operations, I wrote a lot of controllers and their methods in vain.
Questions:
When should I use RestConroller, and when is Spring Data REST?
Is it possible to combine two approaches for one Entity? It turns out that I was wasting my time writing for simple operations like creating, getting, saving, deleting controllers, it can be moved to Spring Data REST.
Will I be able to implement some of the actions that I did in Spring Data Rest in RestConroller? Such as:
Return an entity property value as id instead of object? I mean I have properties for entities that are entities themselves, for these fields I sometimes need to return their ID instead of the whole entity.
Is there any way to control error handling? In RestController I have implemented the ResponseEntityExceptionHandler extension class and all errors wherever they occur in my RestController are handled in the same way in one place and I always know that all errors will return approximately the same response structure.
Data validation will have to be hinged on the fact that it used to be validated on DTOs received from the client. Are there any nuances waiting for me in this regard?
I'm a little stumped on how to move forward. Give me your recommendations and thoughts on this. Push forward on what to use and how.
What Spring Data REST can do for you is scaffolding of the plain repository to rest service. It is much faster, and in theory it should be flexible, but in practice it is hard to achieve something more than REST access to your repositories.
In production I've used Spring Data REST as a wrapper of the database - in a service/microservice architecture model you just wrap-up sometimes the core DB into such layer in order to achieve DB-agnostic Application. Then the services will apply the business logic on top of this wrapper and will provide API for the front-end.
On the other hand Spring Data Rest(SDR) is not suitable if you plan to use only these generated endpoints, because you need to customize the logic for fetching data and data manipulation into Repoitories/Services. You can combine both and use SDR for the "simple" entities, where you need only the basic CRUD over them, and for the complex entities to go with the standard approach, where you decouple the entity from the endopint and apply your custom business logic into the services. The downside of mixing up both strategies is that your app will be not consistent, and some "things" will happen out-of-the-box, which is very confusing for a new developer on this project.
It loooks wasted time and efforts to write these classes yourself, but it only because your app doesn' have a complex database and/or business logic yet.
In short - the "standard" way provides much bigger flexibility at the price of writing repetetive code in the beginning.
You have much more control building the full stack on your own, you are using DTO's instead of returning the entity objects, you can combine repositories in your services and you can put your business logic on the service layer. If you are not doing anything of the above (and you don't expect to in the near future) there is no need for writing all that boilerplate yet over again, and that's when Spring Data REST comes into play.
This is an interesting question.
Spring Data Rest provides abstraction and takes a most of the implementation in its hand. This is helpful for small applications where the business logic resides at the repository layer. I would choose this for applications with simple straight forward business logic.
However if I need fine grained control (eg: transaction, AOP, unit testing, complex business decisions etc. ) at each of the layers as you mentioned which is most often needed for large scale applications I will prefer writing each of these layers.
There is no thumb rule.
I have multiple closely related problems in Spring Security. I am developing using Spring Boot and am using Spring Data REST for creating REST endpoints directly from my repositories.
I have multiple entities and the requirement is to have all these entities as REST endpoints. I am letting spring-data-rest handle the creation of these endpoints and I am securing these endpoints by adding #PreAuthorize and #PostAuthorize to the entity repository methods as and where required. This works great when I am calling an endpoint like /entity/id.
But I am facing issues from here. Let's say I have 2 entities, Entity1 and Entity2 and they have a One to One relationship. Spring data rest allows me to fetch the related Entity2 data from Entity1 like /entity1/id/entity2. But I have different access rights over Entity1 and Entity2 and calling the above endpoint only checks the access rights as set up in the repository for Entity1 only. So, if a user has access to Entity1 table and no access to Entity2 table, he can still see some Entity2 data via the foreign key relationship of Entity1. Is this a correct design?
Moreover we have some custom API endpoints wherein we have to aggregate data from multiple entity repositories. Also, these endpoints themselves have to secured. So, I am using a #PreAuthorize over an endpoint method. This works as expected and the endpoint method is called only when the expression is valid. But, when a repository method is called (via a service class of course), the #PreAuthorize over that repository method is also evaluated. I would like to have the check done with at the beginning. Is it possible to do so?
Any suggestions to improving the design is also welcome.
There is no simple solution without massively modifying/overriding lots of default Spring DataRest features. I'm working such a package for years now and it's working quite well for me.
Although switching to this package might be a bit overkill for you, it could worth the trouble in the long run because it also a fixes a lot of problem you will meet only months later.
you can set up permisison rules via annotation directly in the domain objects.
it checks the permisisons in the DB side, so the traffic between the API and DB is heavily decreased (Only those objects are fetched form the DB which the current user has permission to)
you can set READ/UPDATE/DELETE/CREATE permissions separately for roles and/or certain users
you can use pagination on permission filtered collection
you can use pagination on property-collections too
(+ some extra features like flexible search on multiple properties)
here is the package (It's an extension of Spring Data JPA / Data Rest)
Searched over the net but unable to find the satisfying approach.
I am new to spring boot and aware of starter dependancies,
I want to develop a springboot app using elastic search as a storage system.
Wherever i searched i found that somewhere my service class will have to implement some interface from springframework for ES crud operations.
Is there any other way without implementing or extending the components.
I myself want to create transport client and want to query ES by my code or methods not by overidden ones.
Please if you ahve ever seen any projects you can redirect me to that link .
Thanks.
Assuming I understand you correctly, you can use the Elasticsearch REST client: https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-low.html
You supply the JSON entities for the queries and parse the responses yourself. Its pretty basic in what it does, so you're not dependent on a lot of third party stuff to perform operations.
It's not very clear to me what is the difference between the options below in https://start.spring.io/ select dependencies fields
Web -
Full-stack web development with Tomcat and Spring MVC
Rest Repositories -
Expressing Spring Data repositories over REST via
spring-data-rest-webmvc
The way I see it, Rest Repositories is pure backend dependencies..
I want to create( learn ) a spring project that has an endpoint to specify for a webhook consumption and can send HTTP request to APIs after doing some backend processing
What I understood is (in lame terms), Rest Repositories enable Spring to automatically add "our so-called Controller specific code" & allows developers to skip adding them for simple purposes.
e.g. this page here shows how easy it would be for us to directly query a DB without adding own API & Service layers.
Spring did it all for us. Plus it also added configurations to override them if we want.
Never used spring data rest but it look that it's main purpose is to make rest webservice over a datasource. I think this is limited.
So you should go with a Web full stack.
You can still do REST with it, and if you don't want view, just return json or anything.