This question already has answers here:
How to implement JAX-RS RESTful service in JSF framework
(3 answers)
JSF Controller, Service and DAO
(2 answers)
Closed 5 years ago.
I am learning to build a JavaEE application, and I find that JSF's controller layer very similar to REST service, they all invoke the service layer's methods to reach the same goal. So if I already have a REST service and then want to build the front-end, do I need JSF? Or can I just use HTML/AJAX? To be frankly, the real question I'm now facing is that how to interagte the front-end and back-end together. I'm really confused about it, please help me, thank u so much!
The REST service IS your interaction layer.
Whether it talks to a JSF application, an Angular application, a C# application, Cobol, or whatever is completely irrelevant.
Many REST services never talk to a web frontend at all.
Related
This question already has an answer here:
How can I integrate socket.io on Karate
(1 answer)
Closed 1 year ago.
We are using ReadyAPI for API testing, Mocking and JMeter for performance testing and looking into the possibility to migrate everything to Karate framework. Would be handy to have all in one open source framework. But the main question is: can Karate framework handle JMS calls? Because 80% of our service testing is via JMS (with Hermes in ReadyAPI). I know SOAP and REST are supported but can't find anything about JMS.
Yes, you have to write a Java adapter (one-time work).
Please look at these 2 references:
https://twitter.com/getkarate/status/1128170638223364097
A great example that shows off Karate's
Java / JS interop - and built-in async support
first we call custom code to listen to an ApacheActiveMQ queue
an HTTP POST is made
we wait for the JMS message
and assert that the message is as expected
https://github.com/intuit/karate/tree/master/karate-netty#consumer-provider-example
https://twitter.com/getkarate/status/1417023536082812935
How Java interop and mocks can come together for advanced async / messaging flows such as JMS or apachekafka
link to full example: https://github.com/intuit/karate/tree/develop/karate-demo/src/test/java/mock/async
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Our group used to build web applications using jersey. Usually we would have two modules, dao and api. Dao consists of entity classes and dao interfaces/implementation classes, while Api module has all the rest api classes. Recently, we have been transitioning from Jersey to Spring MVC and Spring Boot. Since we are using Spring Data and JPA, there seems to have no need of having a dao package for all the interfaces and implementations. Instead, JPA repositories take care of all the data access. Services are built over the repository layer. It feels more natural to have the JPA repository stuff in the same module as services, controller, etc.
What is the best practice of organizing a restful web api project? Should I set up the project as a two module application just like what we did before, that is having all the entities in one module (model or dao) and the rest goes to another module called api? If this is the way to go, should I keep persistence.xml which contains all the ORM mapping for entities within the entity module or the api module?
This is mostly my opinion of 1 vs 2 modules, but I don't think there is one single answer. It probably depends on how large the web app is. Is it a single API in the same codebase/build that's basic CRUD or do you have many separate, but smaller APIs creating more of a micro-service environment. We had a few larger monolithic apps where we did separate out the Dao stuff into separate modules. We also separated 3rd party dependencies such as Google or Stripe into a module even separate from Dao stuff. Makes it easier to create a separate jar if there was a need.
Regardless, what's more important is you can ensure you have one way dependency. Meaning the API is dependent on the DAO but not the opposite. Curious what others think
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
we're developing kind of a social network.
We first focused on mobile applications and thus we developed our own API (REST) using jboss as application server and everything is fine.
Now we are beginning the development of a website. We decided to build such website on top on the API we already have, so we won't have to worry about the database management.
My question is: what approach should I follow?
client-side calls (using ajax)
server-side calls (using e.g. php, python) to dynamically generate the html page
Do you have any suggestion?
Thanks,
Andrea
I like a mixed approach.
Direct client side calls into your REST layer will have issues with Authentication & Authorization.
So you need to have a server-side Facade that validates application session and then allows the calls to pass through to your backend.
This layer can employ pagination kind of logic if the REST APIs have them missing.
Sometimes an UI action would require you to manipulate the data structure or multiple REST calls to create the resulting view. Direct one-to-one mapping of UI action to backend REST calls may not be possible. There also this facade helps make the APIs more UI friendly.
Finally - for some static / cachable HTML fragments your server can generate the view from REST layer and cache it for faster serving.
So in summary
Use node.js or playframework kind of AJAX based UI to build the UI layer.
But to use a Facade that orchestrates, aggregates, transforms, authenticate, authorize the UI calls before hitting the REST layer - to keep the UI experience simpler.
I'd like to build a restful service to return some JSON data to a mobile application. I've worked with Grails in the past - it's pretty much perfect for this - but I'd like to learn Spring for my own purposes, mostly because it's the dominant Java-based server technology. So, I'm thinking about building the service in Spring MVC 3 for my own edification. But, one problem already is my hosting service doesn't support Spring - nor Grails for that matter. They do support Ruby on Rails and PHP.
My question - how heavy of a learning curve is it to get Spring up and running with a restful service? Is there a really good tutorial/learning resource to learn Spring in a short amount of time? Also, will it be difficult/expensive to find a hosting server? Or should I throw in the towel and go with Ruby or PHP?
There are loads of tutorials and some very good ones as well
This one was recommended by SpringSource a couple of weeks ago. It's in 5 parts so make sure to check out the other ones as well :)
At first glance it might look like alot of work but it really isn't, you do the initial wiring pretty fast and then adding new Controllers are really simple so in long term it's going to be fast and easy.
I want to use EJB in my GWT Application, but I coulnd't find a current Tutorial. I am new to the topic of EJB's and with GWt I have worked the last months. At the moment I have got some RPC Calls in my GWT Application and this works. Is it's possible in GWT to use EJB and if yes would it be difficult to install?
GWT is a client-side framework. It can connect with the server-side i.e. using RPC calls, REST web services or SOAP web services. An EJB on the other hand is a server-side technology which can define several entry-points for its clients.
I would consider creating a proper business logic and create a boundary for it - in form of i.e. RESTful Web Services. This functionality can be tested in well-controlled environment or even in real-life application server.
If this is done, than you just need to create a regular GWT application which 'talks' with EJBs through REST-WS.
Sorry, but I'm not aware of any tutorials about GWT + EJB. There is an example of EJB RESTful implementation at Adam Bien's weblog, but if you're really interested in EJB technology and don't know a bit about it, I would recommend to take some decent book first, like Enterprise Java Beans 3.1.