I am creating a RESTful web service and I need to map the methods that I want to expose as paths. I got one question regarding the organization of service classes.
Is it normal to create one service class that is the endpoint of the application which internally delegates to other service classes?
And how do you organize methods and paths belonging to a resource? Do you create one MyClassCrudService class, one MyClassOperationsService class etc? And then add that path mapping annotations on each class, or do you create one MyClassResourceService class?
I find it hard to divide the service methods in different classes, and naming them properly.
I could need some guidance on how it is normal to organize the services.
I would recommend starting with one Resource class per logical resource and only adding complexity when necessary. Definining necessary really just takes experience and developing a personal taste or team standard.
If you're new to REST, I would also recommend Bill Burke's RESTful Java with JAX-RS.
Related
I have DAO interface and DAOImpl class on my Spring boot REST API project. But some of my teammates were telling me that it is not necessary to have an interface in REST API.
Their argument is if the code is shared as a .jar file (eg. Database Driver jar file) then it is necessary to have an interface. Since jar is added in the classpath and the end user can override the methods defined in the jar file. Whereas REST API's are deployed in servers and can be consumed by any programming language via HTTP
I know there is no concrete answer for this. But I just want to know the advantages/disadvantages of having an interface in REST API / Microservice
The advantage of using an interface is when you use a service that is common by all your Rest API like the security service with spring-security.
"interface" is NOT specific to REST API (or) Spring, it is one of the Object oriented principle, in Java programming terms, it is "interface".
Your friends are partially true.
In general "interface" are used to define the "protocol" and let the implementation be specific to "implementer".
Now the counter argument I can make is, what if your company wants to standardize the process between "departments" (or) "projects", specific to this DAO business specification (forgot about sharing as .jar or something else)?
Interface is the best practice in this situation and it takes 1 minute to implement.
Once I did a hiring test to a company in UK and i got this feedback:
"And the dreaded Impl classes…"
At this point I started questioning the use of interfaces in microservices where everything is accessed through HTTP. After putting some thoughts into this I realized I never had a situation where Interfaces were really helpful in this situation.
I built a few personal projects without them (unless it's required by Spring) and I liked it. Being able to change services without painting them red by the IDE was a big plus.
Also, it's less code to maintain. I would vote up for it for new projects.
I'm working on my first app in Spring and I have a design problem. I've created a few services that I'd like to use through a few facades (is it good idea?).
I'd like to have structure like this
/services
/facades
/interfaces
**facades**
/implementations
**sampleFacades**
/interfaces
**services**
/implementations
**sampleServices**
with package-private services (interfaces and implementations). Is it possible or I have to put all classes to one package?
The Facade Pattern is meant to create a simplified and dedicated access to more complicated code.
Typically you would have an API created by someone else and you would then create your own custom API to consume the other.
In this case you seem to be creating façades to Services in within the same Spring Applicaiton, which to me does not really make sense.
Why create façades when you have control over the service definitions?
If there is a need for a façade for your own service, perhaps they are not defined at the right level of granularity?
Note that some of the complexity of the Services should be addressed by other patterns such as Data Access Objects coordinated by the Services.
Regarding your question on putting all the classes in the same package, consider the Bounded Contexts of Domain Driven Design and organize your code around the domain instead of implementation details.
I'm developing a small web app with Spring and java. And came up with a question about package names.
I have a layer separation app, having:
-the "web" layer with my controllers
-the "domain" layer with my model
-the "connector" layer, in charge of doing http communication with external web services
-the "service" layer, with contains my bussiness and app logic.
I have transformers, comparators used for sorting and other classes, all are used inside my service layer, because are part of the bussiness logic. My question is, should the transformers be inside the service package, something like "service.transformer", and same with "servcice.sorting", or should they be a completely separated package, outside the "service" package?
I'd like to hear your opinions
There are a couple of considerations to be made when packaging your classes. First, where are the classes used? And, second, how should they be packaged? Regarding the first, you say that your transformers, comparators and associated miscellaneous classes are only used by your service classes. If so, then it makes sense to put them inside your service package.
Regarding the second question, you should think about whether they would ever need to be used elsewhere in this project or another. If so, then you might want to package them at a higher independent level. That makes it easier to package them up into their own library for use elsewhere.
If your using a modern IDE, I wouldn't think too hard about it since it is trivial to refactor your code later as needs change. For example, in Eclipse adding and optimizing import statements, or moving classes from one package to another is a few keystrokes.
I want to create an java API to connect to a Restful API.
To deal with dependencies, I want to use Spring.
However, all examples I see over the internet talks about a DI container, and the whole system is running like a service.
What I need is:
Provide some classes to user be able to connect to such Restful API, but the inner dependencies of these classes being resolved by Spring. Needless to say that this framework won't start any application server. It will just provide some useful classes and interfaces to contact the RestAPI.
Is that possible?
Thanks in advance!
The Situation
Let's suppose I've wrote an API which provides a class called Car. User can use this Car class in their project. But Car class depends on two other classes: Wheel and Engine. What I want is the last two classes to be injected automatically, without the user needing to instantiate this.
The short answer to the situation is: no.
The reason for this is somebody must start Spring.
You have some options.
Solution 1
You can create some kind of initialization class that starts Spring for you.
The API user would need to do this:
Call the initialization stuff. Possibly something as simple as myAPI.initialize();.
Then use your stuff.
A giant (imho) drawback of this is that every class in your API would need to check to see if initialization happened.
Solution 2
Expose your classes via a factory. In this case, the API user would do something like this: MyFactory.createCar(...parameters...);
With this technique, the Spring initialization would be hidden from the user because you could load Spring in a static initialization block in the MyFactory class.
Solution 3
Instead of a factory patter,
use a builder pattern to instantiate your classes.
This is, effectively, a variation of the factory solution,
except that each Builder would call a static initialization method of some hidden (perhaps package access) class that starts Spring once.
Option other
If you only want DI,
Spring may not be a good fit for you (it might be overkill).
Google guice is a "just" DI tool that might be a good fit.
Even with guice,
somebody will still need to start it,
so solutions 1-3 will apply.
I have a very large java application with interdepent classes, it is being decided to convert our big application into modules. To start with this task, I would like to gather ideas.
My questions is almost same as asked here : How to modularize a (large) Java App?
Re-asking this question mainly because it was answered 5 years ago. Any new ideas are welcomed.
This isn't the full answer to this question, I believe the link in the question is still valid.
This answer is meant as some process suggestions.
One way to start is to create facades. Initially on paper decide where the boundaries of your modules lie. (which classes are part of a group of classes that make up a module) Then create a facade class (depending on the framework you use, implementing singleton or using spring for ioc) Then whenever you access a class from outside your module, have the outside class call the facade, and have the facade call the actual class.
If you have an external class do several calls on module classes then either this class belongs inside that module, or you need to extract the macro behaviour (series of calls and interactions) into 1 method and move that method into the facade.