I have a page html let's call it abc.html
There are AngularJS fields embedded in it.
I am now writing a GET and POST in scala which routes the fuzzy search arguments to the proper page on the server.
I am trying to understand the sequence in which things occur in order to implement a GET/POST requests (written in scala) which would happen when someone makes a search on the search bar on the abc.html page, and which would return elements from the database
Is it abc.html (search) --> http GET request --> backend ( AngularJS) --> Database?
In this case this would mean my http post or get request would pass in the html data model elements which would in turn hit the backend AngularJS controller page which in turn would hit the database, and the return ride would send the database results via an http request to the page?
Do I need to explicitly define my GET in terms of angular fields and the database model?
thanks
HTTP uses request-response pairs. This means you don't have to make another request to return anything to the client, you just need to write the proper response. Other than that, your idea is fundamentally right. The process would look something like this:
Type something into the search form on your HTML page
Submit the search form to your backend. This creates a GET or POST request depending on your form element's method attribute.
(At this point the browser is awaiting a response)
As the request reaches the server, your backend code can capture its data and make a query to your database.
(At this point the server is awaiting data from the database)
The database returns its results, your backend code is free to format it into a response to the client's original request.
The client receives the response and you can use your frontend code to display it to the user.
Related
Is there a way to only show a clean url when doing a get request?
i.e. someone is send to a page:
http://domain.com/?param1=1¶m2=2
And the user only sees :
http://domain.com
I tried it with a post-request but then you get these annoying pop-ups when someone refreshes the page or hits the back button.
Doing a post-redirect-get is also not possible since this increases the response time to much and the page is generated dynamically so it needs the parameters.
You could use URL rewriting when you are using Apache.
Or similar functionalities in other web servers.
There are 3 ways to pass parameters from a client to a server:
GET request; which you don't want to use
POST body (includes post-redirect-get); you don't wan to use POST
request header
The way to have a client pass arbitrary parameters in a request header is cookies.
I am trying to build a website using Ruby on Rails that presents a question to the user(say on page1). After the user submits an answer to the question he goes to page2. I want to record his response, check with my database for its correctness and I want to give a feedback and also present the next question on the same page(page2).
I want to conceptually understand how can I do the above. When do I use HTTP GET and POST?
Data Persistence
I want to record his response, check with my database for its
correctness and I want to give a feedback and also present the next
question on the same page(page2)
This will likely be achieved using a session based model - whereby the question response is created sequentially:
#app/models/form_response.rb
class FormResponse
def initialize(session)
#session = session
#session[:form_response] ||= []
end
def process_response(response)
#response here
end
...
end
This will allow you to store the response, and evaluate over time. There's a great Railscast about it here:
In terms of the POST / GET requests, I'd be tempted to use POST, as this will keep your application modular (the params are not stored in the URL etc)
The way to do this would be as follows:
#config/routes.rb
resources :controller do
collection do
post :page1
post :page2
post :summary
end
end
#app/controllers/your_controller.rb
Class YourController < ApplicationController
def page1
#form = FormResponse.new(session)
render :page2
end
end
--
Ajax
You'll may also want to use ajax for this
Ajax is the ability to send an asynchronous request to your application, through JS. In fact, Ajax actually stands for Aysnchronous Javascript and XML, which means you need to be able to use it to send a hidden request to your controller, processing the response as you require
You'll want to use this for UX more than anything (the ability for a user to stay on the same page to edit their response). I can detail more about this if you wanted
This sounds more like a general question about HTTP than Ruby on Rails so I'll approach it that way. At a high level the HTTP exchange will look something like this:
The user/browser sends an HTTP request to your server and waits for a response. This can be, for example, a GET or POST request.
Your server will process that request (eg. using Rails in your case) and send an HTTP response back to the user. The response will contain a status code and an optional body.
The user/browser receives the response and processes it. The response body often is the HTML markup of a web page, in which case, it will be rendered in the browser. The page may contain links or forms that the user can click on or submit, which then brings us back up to Step 1.
I'd suggest you read more about the HTTP protocol (eg. on Wikipedia)
Title question asks it all, what's the process going on under there? Why do I have to use AJAX if I wanted to submit that form asynchrously?
It's due to the way HTTP was designed. Back then, JavaScript was not as ubiquitous and not as powerful as it is today.
As it is, when you POST data to a page (a path), you are issuing a request to a server. The server can then respond in a variety of manners. There is the simple "return some content", whether it be HTML, text, JSON, XML, etc. There is also the possibility for the server to return a redirect, sending you to a different location.
What AJAX does is simply to run this request in the background and hide the fact that data was submitted to the server and a response was returned from the user's perspective.
I am creating a dashboard application in which i show information about the servers. I have a Servlet called "poller.java" that will collect information from the servers and send it back to a client.jsp file. In the client.jsp , i make AJAX calls every 2 minutes to call the poller.java servlet in order to get information about the servers.
The client.jsp file shows information in the form of a table like
server1 info
server 2 info
Now, i want to add one more functionality. when the user clicks on the server1, I should show a separate page (call it server1.jsp) containing the time stamps in which the AJAX call was made by calling.jsp and the server information that was retrieved. This information is available in my calling.jsp page. But, how do i show it in the next page.
Initially, i thought of writing to a file and then retrieving it in my server1.jsp file. But, I dont think it is a good approach. I am sure i am missing a much simpler way to do this. Can someone help me ?
You should name your servlet Poller.java not poller.java. Classes should always start with an uppercase. You can implement your servlet to forward to a different page for example if sombody clicks to server1 then the servlet will forward to server1.jsp. Have a look at RequestDispatcher for this. Passing information between request's should be done by request attributes. if you need to retain the information over several request you could think about using session.
In the .NET world, we use SessionState to maintain data that must persist between requests. Surely there's something similar for JSP? (The session object, perhaps.)
If you can't use session state in a servelet, you're going to have to fall back on a physical backing store. I'd use a database, or a known standard file format (like XML). Avoid home-brew file formats that require you to write your own parser.
I have a URI for a collection of resources called 'facts', and URIs for each 'fact' resource in that collection.
The form for creating a new 'fact' should be requested with a GET, I believe, but I'm having trouble deciding what URI it should be made to.
A GET to the collection URI should return a list of the 'fact' resource URIs. Each 'fact' URI should return its contents as a response to GET. The actual 'fact' creation would be a POST (or PUT, depending on the situation), of course.
I see a few options, but none seem satisfactory:
Add a 'fact form' URI which the 'facts' URI will reference. A GET to this URI gives the HTML form. Seems wrong to have another resource just for a description of a resource.
A POST made to the 'facts' URI without including any form data in the headers would return the form. Then after the user fills the form in, it would POST with the form data, and create the new 'fact' resource. This seems like an even worse approach.
Don't send the form over the wire, but include it as part of the API. This seems RESTful since a REST API should describe the media types, and a form can be made from a description of the 'fact' type. This is weird to implement. Maybe the REST service is separate from the regular web site, so that the actual HTML form request is at some URI apart from the REST API.
Include the HTML form as part of the 'facts' URI response.
To clarify, I'm trying to follow true REST architecture as specified by Roy Fielding, not half-baked RPC posing as REST.
edit: I'm starting to think #3 is on to something.
edit2: I think a solution is to have regular non-REST HTML navigation in a CRUD manner, and then the frontend makes AJAX REST calls as appropriate (or the backend makes internal calls to its REST API).
The reason I need to do the REST part of this service correctly is that I want to allow other non-HTML clients to interact with it later on.
In my mind, the only cleanly RESTful answers are 1 and 3.
As I see it, the description of the resource is a resource of its own. The question is whether you want to make this resource accessible through your application's API or if you want to make it part of the API itself.
For 1, it seems RESTful make the URIs something like this:
GET /facts -> all facts
GET /facts/1 -> returns fact 1 (obviously the id might be a word or something else)
GET /facts/create -> returns a form appropriate for creating a fact
POST /facts -> adds a fact
I think you're overcomplicating things a bit. A web browser is just not a perfect REST client, so you can't have a perfectly RESTful solution. In a perfect world, you would not need a form at all, because the web browser would know your media types and build the form itself.
Meanwhile, I suggest you just use what most REST frameworks would call an additional "view" on the resource to return a form:
E.g. /your/collectionresource?view=form, or /your/collectionresource;form