How to save state of GET request url java spring rest - java

I have RESTful app which reacts on GET request and I need to store the state.
For example
localhost/subs?search=John
Then I need to add other parameter division by clicking button.
localhost/subs?search=John&division=develop
Meanwhile the data output will be distributed on pages. And appear new 2 parameters size and page.
localhost/subs?search=John&division=develop&size=5&page=0
In this situation when I click on next page button my url is resetting.
I’m really confused. How to save state and if parameter is already has in url then it should be changed for new value, if parameter doesn’t exist then append it.
If there good options?
At least I can use JavaScript by taking it and parsing url.
But I think it’s not good at all.

As I know, the RestAPI doesn't save any request parameters (Maybe you can do by adding them into a session attribute, but it's just made the logic code become more complex).
At least I can use JavaScript by taking it and parsing URL
Yes, I think you should.
Happy coding!

Related

Using request across 2 different struts-action flows

I have a struts action flow(struts-1.x framework), which, when executes, the action class ActionFlowActionUnit1.java sets a String variable varName to request using the code
request.setAttribute("varNameFromRequest", varName);
and the flow finally leads to the loading of a jsp Page1.jsp.
Now, Page1.jsp contains a button, which, when clicked, initiates a new struts action flow, which has the action class ActionFlowActionUnit2.java. In this class, I want to use the varName which I had set in request using request.getAttribute().
How can I do it WITHOUT USING SESSION?
Technically, I'm not sure if achieving this using requestis possible, because, triggering a new struts-action will lose all other information in the request that was previously set (if I'm correct).
I couldn't get anything from Google.
As you say, it is not feasible technically as you want it (every http request from the browser creates a new HttpServletRequest object)
You have 2 options:
Using the Session, which you want to avoid as far as I understand
Bring back and forth some parameter into every successive request with the value you would like to keep.
The second option would mean to store some parameter inside your Page1.jsp <form> with the variable you need your second action to receive, and then rinse and repeat. This is a pure html form solution.
If you are implementing a complex flow, this looks a fair case to have a look at Spring Webflow. There you can manage flow-level variables, which are stored at a "different" scope than request or session, and looks exactly what you want.
http://projects.spring.io/spring-webflow/

Why does images.google.com GET requests have such an un-readable form?

Particularly, what are all the dots and numbers at the end for.
Here is an example:
https://www.google.com/search?site=&tbm=isch&source=hp&biw=1366&bih=673&q=kale&oq=kale&gs_l=img.3..0l10.403.1120.0.1352.4.4.0.0.0.0.407.543.0j1j4-1.2.0....0...1ac.1.32.img..2.2.542.vC-f2Kfx-2E
It is a GET variables value, but why such a strange un-human readable syntax?
I assume they are using PHP or Java on the back-end.
What you are seeing is internal computer data, not exactly intended for normal human consumption, but there for a good reason. Also perhaps you are thinking, why would anyone want these ugly internal details displayed on the average user's screen?
When HTTP was invented the thought was that GET requests should be stateful, in other words, if I copy a URI from my browser and email it to you, and you browse to it, then you should see exactly what I saw. To make this work the GET data needed to be in the URI and not hidden from view. Thus the dirty details you are seeing. Back in the day they were thinking of simple GET queries, for example: http://www.somedomain.com/Search?Find=FooBar
However, as software has evolved more data needs to be passed with GET requests and unfortunately it is all visible in the URI. (Note that this also becomes a minor security hole because the average user can see some of the internals of web page production and easily tamper with it.)
What is needed is a hidden data passing method for GET type queries to clean up URIs when it is not necessary for these details to be present. A proposal for such an improvement to HTTP is in the process of being considered. It would involve adding a new method to HTTP similar to GET but with hidden data passing like POST.

Spring MVC recovering page state after saving

I have a Spring MVC application where I sometimes have to add a new object to a list, and at some point, save the page. At every point where I need to add something to a list, a controller action is called and when it is done adding it returns the page. The state of the page then is lost. (ie. scrollbar position). I would like to preserve the page state, also after saving the page (which does a redirect to the new page)
Right now I am putting some variables in the session, and reading them out EVERY time. I find this quite ugly.
Does anyone know like a solution to this? Or any third party dependency which can make my life easier on this? :)
Thanks in advance.
Ps. I hope my question is clear, and not too abstract. If so, I will try to clarify it more.
One way to avoid the complete page refresh is to use ajax. Submit the new List item via an ajax request and the browser will not perform the full refresh.
Exists another variant. You may perform AJAX call to Controller method and send only the data you need to save. After that through #ResponseBody annotation you can return refreshed data or any other result. So this solution force you to use AJAX call. You may use JQuery for this purpose.

Managing webapp session data/controller flow for multiple tabs

I have a Java web application which stores some data in the session. The data in the session changes as the user interacts with the application (e.g. flow is managed by a controller, each controller has several form pages, on each form page some data is updated in the session and flow goes to the next form page).
The problem is that some users are opening more than one tab to the application, each tab with a different step in the flow. At this point data in the session is messed up since the tabs share the same session (app uses cookie managed sessions).
Telling the users to use different browsers to avoid sharing the same session id (e.g. one Firefox window and one IE window) is not an option since surely at some point somebody will forget to do this and instead use tabs, thus messing up their data.
Adding some verifications that detect that another flow is requested from another tab and display a message to the user saying this is not allowed is not an option either since it pisses of the users and we don't want that do we? :D
The fact is that using another tab is useful for the users because they are more efficient in what they use the application for, so I am keeping this option. But the question now is how best to manage the one session data for the more tabs?
What I thought of, was to have the controller generate a token when it starts the flow and pass this token to each form page which in turn sends it back to identify itself. If another tab requests the same controller action when there is an ongoing flow then generate another token and pass that around.
Basically, I want each flow to have a token and inside the session I won't just keep one set of data but have a set of data for each token and then match requests based on the token.
Now the problem is that this approach will need a lot of rewritings to the application and I was wondering if there is a best practice for managing such a situation or can someone suggest other approaches. I am open to ideas.
Have you encountered this situation? How did you handle it?
This is usually done by assigning a windowId for each tab/window and passing it on each request. Jsf supports this via orchestra. Spring mvc will support it in the next version.
I recently needed this for a simple case, so I implemented it myself. Took half an hour. However, my scope was very limited:
pass a windowId with each request, and return it back for the next request. The first time - generate it.
for any attribute you want to store in the session, put a Map<String, Object> where the key is the windowId
This is exactly what Seam was created to handle. In Seam there's a concept called a Conversation which basically does exactly what you are explaining. Conversations are basically are a way to divide the Session into many pieces that can expire at some timeout. You can look at the source code for org.jboss.seam.core.Manager class to see how it's actually implemented and get inspired ;)
Depending on the complexity of your application, you may want to investigate implementing tabs within your application. This gives you wholesale control over the flow, while still providing users with the functionality they want. I'd argue it's, bugwise, the most robust solution, since you won't have a dependency on the way the browser handles sessions, minimising the number of "known unknowns".
Of course, there'll be potentially a large upfront cost to this, depending on how your application is structured. Without more information about your app, you're the best placed person to decide.
You can also try to wrap your application inside Adobe Air
And then limit your web application to be only accessable from this air. By doing this you dont need to consider the web browser fragmentation and their unique behaviour.

Clear HTTP Session

I am trying to clear everything on my HTML form when I visit it from a hyperlink entry.
Any ideas? My development language is java.
are you using session-scoped data? if so, close your browser and open it again.
I'm not sure the application is, but one way to accomplish this would be to use JavaScript. For example, if it is acceptable to clear the form every time that page is visited you could write a quick function that clears the form when the page is loaded (i.e., using the onload event).
If you only want to clear the form when the page is hit from that link you could add a param to the URL (e.g., clearForm=true) and use JavaScript to pick up the query string and clear the form when that parameter is present.
This is, of course, a purely client-side solution. For a server-side solution it would be helpful to know what framework you are using.

Categories