I want to make a POST HTTP request from a struts2 action to an external URL and send parameters in the request.
I have read that it can be done in this way: External django redirect with POST parameters but I was wondering if it can be done in a different way, let's say, directly from the action and not throgh a JSP.
Thanks for any suggestions.
It depends on what you're actually trying to do.
If you're trying to make a request from your action to another site, then do something with the response and return data to the user without the user knowing the external site was accessed, then you'd need to use something like Apache's HttpClient. That can be done anywhere, bt obviously doesn't belong in a JSP as you state.
Related
I'm looking for any way to run PUT and DELETE methods for Java Servlets. In general, I have a simple application with web control (WAR) connected with EJB project that controls a simple list of libraries.
For each of CRUD actions I would like to use different different method:
Creating by POST,
Reading by GET,
Update by PUT,
Delete by DELETE
However create I make by simple form with post method, read (list) is executed by simple entering GET in the URL address (without form), but I have no idea how could I use put and delete for their purposes.
Unfortunately online resources I found didn't answer that question, but I'm just curious how I could use id.
I assume removing by e.g. /Servlet/:libraryId (without any body), update by the same URL schema (with updated schema). doPut() and doDelete() should just run proper actions in the EJB.
There's no way on the HTML level to create a DELETE request in a form submit (it's always GET or POST, except you start to write your own browser that handles the kind of non standard HTML you proposed), all you can do is to submit a value (taken from a hidden field, radio button, whatever) that expresses which action should be taken in the doPost() or doGet() handler on the server.
But then there's nothing special about DELETE on the http protocol level. The whole request is just a sequence of bytes, where the first few define the method (PUT, GET, DELETE, PATCH...), followed by space etc.
As far as your server is concerned you could even use web sockets to accept connections and create responses to self defined fantasy methods. If you're using servlets, you have doPut(), doGet() and doDelete() available anyway. To handle other http methods you'd have to override the service() method.
On the client side Angular's HttpClient allows for all three methods that you need, you could use jquery's ajax, or there's again the web socket approach on the client too, as long as the browser plays along.
If it is a Java client, again there are web sockets (but you'd want to send some valid http request instead of "Hello", as done in the example¹.), HttpUrlConnection and the Apache HttpClient, at a first glance.
As for testing, there are browser extensions available that let you compose requests other than PUT and GET, SoapUi as a tool is very popular, IntelliJ even has a http client, that allows you to type the complete request as plain text.
¹ If you have a hand crafted server that agrees to such a "Hello" protocol, that's fine too. Its just not http.
Since there was quite some confusion in the question, as it turned out, I'd like to promote the idea some more to write your own Http client/server with webSockts. You have ready made examples for the socket stuff, so that's easy.
But it's more interesting then, that you're at the raw tcp/ip level that http is built on, all this framework-redirection (servlets, whatever) drops away and you're left with a single text basically (well, a byte stream), that's the http request. All the magic is gone, things are obvious and simple, just as specified.
How can we know the name of the page or service or state of page which has called RESTful API in java file. Something like $state.current.name in AngularJS.
I have created api's in java using #RequestMapping(). In this java file I want to know about the name of page that has called this API. As I want to call same api on different pages and want to log different strings according to the page which has requested the API. I am using $http.get(api) in AngularJS to call API.
We found the most reliable way to achieve knowledge of the current URL/state is to send it as part of the request payload. This gets around issues of HTTP referer header stripping. You already have $state.current.name, so adding this to your API-calling JS service function should be straightforward.
If you need to add this to every request, one option is to use an interceptor to add the metadata into every HTTP request which contains JSON.
I am working on a project that uses Spring MVC, and one of the requirement involves sending request to an external services to handle some transactions.
The problem now is the external services only takes POST method, and I've looked everywhere and could not find a way to forward user to external site as a POST request(similar to form submit).
What we are trying to do:
1) My Controller will receives request and execute some backend thing and construct some parameters to pass on.
2) *Send request to external service via HTTP POST method with some parameters.
(note. User's browser will show URL of the external site.)
I've looked into different return types for Spring MVC and could not find anything that fits.
Any advice would be greatly appreciated.
Thanks!
You can use the Apache HttpComponents library to send HTTP requests from you controller. It's easy to use, and there's plenty of documentation and examples.
Supposed that this is not an issue related the Spring MVC. That's the same solution Which you try to implement such operations in Servlet I think.
First of all, this external site should be an async service and you neednt get the response from it, right? If yes, i think the simplest solution is that you can new URLConnection within your Servlet or Controller, construct the params and set the POST method, and then send out the request. After that, you can response to your local page as you like.
The second solution, a dummy JSP page is needed. The page will post a form to external service and redirect to the target page as you needed. No matter you use a javascript or not, I think the user will see a refresh on the browser.
You won't be able to redirect as that implies a GET.
Since your client is using a web browser, it should be possible to return an HTML document with a form, and then to submit that form (with a method attribute of POST) when the page has loaded.
can anyone tell me. What exactly is Ajax request? Is it different from Servlet Request?
An Ajax call is an asynchronous request initiated by the browser that does not directly result in a page transition. A servlet request is a Java-specifc term (servlets are a Java specification) for servicing an HTTP request that could get a simple GET or POST (etc) or an Ajax request.
An Ajax ("Asynchronous Javascript and XML") request is sometimes called an XHR request ("XmlHttpRequest"), which is the name most browsers give the object used to send an Ajax request, because at least initially Ajax calls involved the sending and receiving of XML but now it's just as common to send/receive JSON, plain text or HTML.
A good example of an Ajax request is the comment system on Stackoverflow. You can enter a comment in the textbox and click submit. It doesn't submit the whole page (like a traditional HTML form submission would, which translates into usually a POST but sometimes a GET HTTP request). Instead the browser will send probably a POST request via XHR to the server and be notified of the response (hence "asynchronous"). But the server typically can't distinguish between an Ajax request or a page transition because both simply come down to HTTP requests.
Ajax, or Asynchronous JavaScript and XML, is an approach to Web application development that uses client-side scripting to exchange data with the Web server. As a result, Web pages are dynamically updated without a full page refresh interrupting the interaction flow.
With Ajax, you can create richer, more dynamic Web application user interfaces.i.e. client side.
On the other hand servlet requests are on server side to handle request sent from the UI.
When the visitor requests a page, the server will send the full HTML and CSS code at once. After the visitor fills in a form and submits it, the server processes the information( Servlet Request object provides client request information to a servlet. The servlet container creates a ServletRequest object and passes it as an argument to the servlet's service method) and rebuilds the page. It then sends the full page back to the client. And so on.
When using AJAX, the page is loaded entirely only once, the first time it is requested. Besides the HTML and CSS code that make up the page, some JavaScript files are also downloaded: the AJAX engine. All requests for data to the sever will then be sent as JavaScript calls to this engine. The AJAX engine then requests information from the web server asynchronously ( servlet request object contains request parameters,which have got changed). Thus, only small page bits are requested and sent to the browser, as they are needed by the user. The engine then displays the information without reloading the entire page. This leads to a much more responsive interface, because only the necessary information is passed between the client and server, not the whole page.
For more info on ajax implementation we can refer http://www.ibm.com/developerworks/library/j-ajax1/
The problem is that, like so many terms used in IT1 there is no clear definition of either an "AJAX request" or a "Servlet request". The best I can come up with is the following:
AJAX is short for "Asynchronous Javascript and XML", but these days the term is stretched to include JSON or YAML as well as XML. The key idea is that logic embedded in the web page (in Javascript) makes asynchronous HTTP requests back to the "home" server to request more information, rather than triggering a refresh of the entire webpage.
An AJAX request is a request made by an AJAX application. Typically, it is an HTTP request made by (browser-resident) Javascript that uses XML to encode the request data and/or response data. The standard way of making an AJAX request in Javascript is to use an XmlHttpRequest object, but that is an implementation detail ... not fundamental to the definition of AJAX.
A Servlet request is a request made to a Servlet. In theory it need not even be an HTTP request, since Servlet technology is (in theory) designed to work over other protocols as well. To my mind, this is not a particularly useful term.
So ... an AJAX request can be a Servlet request or not, and a Servlet request can be an AJAX request or not.
It is worth pointing out that there is a Java interface called ServletRequest that forms part of the J2EE APIs. This interface is a type of the object that is used to pass details of a web request around in a J2EE-based web application container. So when you see someone use the term "Servlet request" they may actually be talking about a ServletRequest instance.
1 - Actually, this is no different from any other natural language. Words and phrases gain meaning depending on how people use them, not based on any definition you may find in a dictionary. The dictionary "definition" tends to arrive years or decades after a word or phrase comes into common usage, and it gives a meaning based how the word is (or was) used, rather than being a specification of a meaning.
Ajax is not a programming language or a tool, but a concept. Ajax is a client-side script that communicates to and from a server/database without the need for a postback or a complete page refresh
An AJAX request is made (using Javascript) from the client, while a servlet request is made (using, I suppose, Java) from the server.
I suggest you look it up on Wikipedia or some other place.
Ajax requests are calls to the web server. It is up to you how you want to handle it. Servlet is definitely one way.
I am quite new to ICEfaces but already have experience with JSF/Facelets and the Java EE in general.
Currently, I am not using to much of ICEfaces except some utility tags like outputStyle and outputDeclaration, but even this is really nice to have.
Even though I plan on using some AJAX functionality later, I have some h:forms (or ice:forms) which I would like to send as normal JSF POST requests, without going via /block/send-receive-updates. The reason is, that I want to use a filter, which acts on the requested URI, which is impossible if everything is sent to /block/send-receive-updates.
Is there some way to do this?
Edit: To clarify what I want to do:
The web site we are developing consists of publicly available pages and some which only registered members can access. The standard FORM-based security mechanism as defined in the servlet standard is pretty inflexible, as it only allows to define a single login page which is shown, when someone wants to access some restricted content. Because we also want to user to be able to log in by using a small login form visible on every page, we developed a filter, which handles authentication and authorization almost like the web container. It redirects to a custom login page if the user is not authenticated/authorized, but also allows to authenticate a user from a backing-bean. To make it work almost transparently it wraps the HttpServletRequest to supply the Principal and the user roles.
When the filter redirects to the custom login page it saves the current request to "replay" it later, when the user has been successfully authenticated. To do this, the filter has to be able to detect, if a POST request came from the login page (and thus if the user is now authenticated/authorized). But if every POST is going via /block/send-receive-updates this doesn't work anymore.
Of course I could exclude the login page from being handled by ICEfaces, but this would mean I couldn't use any ICEfaces/AJAX on the login page.
This might not be the best way of doing this, but it might be a way. I'll assume, for the sake of argument, that your header holds your extra login form. If you were to make your header in either a seperate frame or in the main layout page and imbed your JSF pages into an iframe, this might work. The idea being that since it's being rendered as a seperate page, you can handle it in a seperate way.
Also, there might be a different way of handling your security that would make this more IceFaces-y. Perhaps, when you hit the filter and it determines that you're not logged in, it should create a bean (probably session) which holds the information from the original request (URL, parameters, etc.) and the sends you on to the login page. The login page does its thing, adding your security stuff, then uses the information in that session bean to force a redirect to your new page. You can use the FacesContext to get your HttpContext and do a redirect. You'd probably need to play around with the redirect to add any appropriate parameters. Lastly, you should get rid of the session bean.
Finally, I know that there are a couple of Frameworks (Spring WebFlow, springs to mind) that will save your request state, let you do the login, and redirect you back to where you were going in the first place pretty seamlessly (which, reminds me, I think Seam can do this too. Probably Orchestra and your other frameworks as well.)
Hope this helps!
I've been using IceFaces for nearly a year now and haven't yet come across any way of submitting the form without going via send-receive-updates. But I'm curious, you say "I plan on using some AJAX functionality later". The point of IceFaces is that it pretty much transparently adds AJAX to your JSF app. It's an "all or nothing" kind of thing - any page you have which uses IceFaces will use AJAX.
The only thing I can think of you could do is not use IceFaces for the pages you want to use POST requests on - i.e. you could map IceFaces pages to *.iface, but normal JSF to *.faces.
Alternatively, there may well be some other way of accomplishing what you want to do with filters.