My plan is to set up a php-based website except all the dynamic data would be loaded through a local RESTful webservice.
The local RESTful webservices would be created using Java Jersey, which will access a MySQL database. The reason behind this is because I would like all the logic to be handled by Java.
Would this perform poorly? I have created RESTful services before and created php websites but never used them together...would calling a webservice on localhost be a terrible way to set this up?
Yes and no. If you plan to extend this beyond a website, e.g. if you plan to have other applications consume your web services, then I'd say it would be an appropriate design. Otherwise, no need for the overhead.
Related
I have two WEB applications based on two different servers. How I can pass data from the PHP web form, which consists of 5-10 fields, to Java application(Struts2, Spring2) in the most elegant and safe way?
I think cURL should be enough, you can make HTTP(S) requests from one to the othe server.
let the PHP return a JSON object, best would be RESTfull.
let the java code make a REST call
One answer: API. That's what APIs are intended for - communication between applications.
Create endpoint in the JAVA app that acceps the data and does something with it.
In PHP after recieving the data from form make a call to the JAVA app endpoint and send the data there.
For security you may want to use some data encription using oauth (that is if you data requires that kind of security).
You have created an API which will return JSON array.
Call that API from java application and get JSON, decode JSON and use that.
Recently, I have developed a REST WS. but I am not able to find important differences between using scripts PHP in my server to access to a database or to have a RESTful WS in my server to access to the same database.
EDIT
I use this WS to access to a database in which I have information about all the users than use my WS. So, I don't know if exists any difference related on behaviour, velocity, perfomance, etc.
I mean, if I access my WS to access to a database using Java. Is Java only the diference?
Are there any advantages to change the behaviour of my server and implements it as a WS?
I don't know what is that a RESTful WS has to be better than a server in which we run scripts PHP.
I think you might get this question downvoted, as it's not code related.
My 2 cents. No technology or approach is best 100% of the time. it deppends on the scenario. If you're not oppening your service to 3rd parties it doesn't provide much sugar to be restful. If you know you won't provide an api but maybe you might launch an app afterwards, a restfull API would make it much more easier... if not the case, not really an advantage
How to display Backend data using AngularJS in Java web Application.
Do I need to use RESTfull Web Services.
If I don't want to use RESTfull web services, then how should I proceed.
(In my java web application m using Spring and Hibernate.)
AngularJS is a framework used to develop single page web applications which doesn't need refreshing and will act like a mobile application.
For this purpose, all the data required by the front end needs to come from some sort of a backend API. REST is widely used for this purpose in many leading high scale websites like twitter/facebook etc.
You should develop your Java Web Application as an API without no/less HTML pages and use that in your AngularJS front end.
RESTfull web services provide and easy way to integrate your AngularJS frond end with database. It is the most popular one. But it is not the only one.
You can also achieve this via different techniques.
All you need is to make call to a server technology that returns a JSON object.
That particular server technology (even a simple JSP/Servlet) can interact with database and return the expected data in JSON format.
This link provides a simple example to help you begin with.
I'm trying to choose best set of tools to create Single Page Applications. I would like to be able to use Java and Hibernate on server side along with MySQL. But what about ajax layer of SPA?
Maybe I have entirely wrong idea about that and Java and Hibernate make no sense in this case? But than how to implement complex server side operations?
It's rather question of UI part. The page asks a server for pages data. Java + hibernate could be used to implement service (e.g. REST service which returns data in JSON format). You can use SpringMVC to implement the service.
AJAX calls the service and process obtained data.
You can use angularJS for creating Single Page Application. this is the best framework i found for SPA development so far and using in most of projects developing which needs SPA.
for sample application refer to github
and detail about angularJS
We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez
It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.