This page explains the difference between:
- a static web page/site
- a web app
The short version is that a static web page is simply a “file” on the server containing HTML code.
- Each time a request comes to a server for that file, it will return the contents of that file as the response.
- The web page looks the same each time you see it
- It is straightforward and simple.
- Static web pages are typically retrieved with http
GETrequests. (We’ll discuss what a GET request is later in this article.)
A web app, by contrast, is some custom code that:
- runs on the server or the client, or both
- that computes the web page that you see.
This is sometimes called a dynamic web page, since it can change each time you look it.
Dynamic web pages—ones that show pages that can be different each time you see them—can do computations in one of two places: the server side, or the client side.
Let’s try to understand how this works, and what the difference is.
First, let’s understand this point:
- Server side code runs on the remote web server in response to a request for a page. It runs on the server once per request, to compute what is sent back to your browser. By the time the page arrives at your browser, the computation is over.
Most of the rest of this article will focus on server side code for dynamic web apps. We’ll deal with client side code for dynamic web apps in another article later one.
When you bring up a web page in a browser, your browser sends a message to a web server with a request for the URL that you put in the address bar, or the URL that was in the link that you clicked.
The server looks at the URL and then determines whether it is a request—from the server’s perspective—for static content, or dynamic content.
It if is static content:
- The server simple sends back the file requested. That file is typically an HTML file.
- That HTML file might contain references to other needed files, including embedded images (gifs, jpegs, pngs), CSS files (which control the look of the page: fonts, colors, layout, spacing, etc.). So far, we are still only talking about static content.
The request to a web app may also be of several different types, with GET and POST being the most common types of requests.
These various types of requests are called “HTTP methods”.
- Technically, GET and POST are just two of a long list of requests types called HTTP Methods
- The full list of them is defined in Section 9 of the HTTP 1.1 standard, RFC2616, and includes in addition to GET and POST, these types: OPTIONS, HEAD, DELETE, PUT, TRACE, CONNECT
- In terms of learning, its typical to learn about GET first, then POST, then finally PUT and DELETE.
- GET is typically used to simply lookup content, i.e. to retrieve content, but not change anything on the server.
- POST is typically used to change something on the server, especially when a new record is being created.
- DELETE is typically used (no surprise) to delete some content on the server.
- PUT is typically used to update some content, i.e. to make changes to an object that already exists.
- GET, POST, DELETE and PUT requests for dynamic content often have parameters that are used to compute a result. More on that later.
Many of the books, web sites, and other resources you read will only mention GET and POST, and emphasize when to use one vs. the other.
At first, we’ll do the same. Do keep in mind though, that as your understanding of web applications progresses and you move into the topic of RESTful APIs, you’ll need to move beyond just GET and POST.
A request for static content typically uses the GET method. We’ll discuss the POST method later in this article.
A note about this word “method”:
- If you are studying Object-Oriented Programming, you may know a specfic meaning of the term method, but don’t be confused.
- The word method here is being used with its ordinary English meaning, and then being defined as a specific technical term in the context of HTTP.
- HTTP methods are not methods in an OOP sense; rather they are different ways (different “methods”) of making an HTTP request.
A static web page is what you get when you make a .html file, and put it in your public_html directory on CSIL. As an example, you might:
- put the HTML code below into
- store it under the directory /cs/student/yourname/public_html
- Do these chmod commands so that the Apache webserver process on CSIL has access to it:
- Access the page at http://www.cs.ucsb.edu/~yourname/sample.html
<!DOCTYPE html> <html> <head> <title>Sample web page</title> </head> <body> <title>Hello, World!</title> </body> </html>
When you put the URL http://www.cs.ucsb.edu/~yourname/sample.html into your browser and hit enter, the browser sends an HTTP message to the server called a”GET” request, and the server responds with the contents of the requested file. It’s up to your browser to make sense of the HTML that is returned, and display it properly.
- Your browser divides the URL into two parts: http://www.cs.ucsb.edu (the host) and ~yourname/sample.html (the requested resource on that host).
- The browser opens an HTTP Connection to the host, www.cs.ucsb.edu, which is running the Apache webserver.
- The Apache webserver on www.cs.ucsb.edu is configured so that when it gets a request for a resource formatted like ~yourname/sample.html, it looks under the home directory of user yourname for a directory called public_html, then for a file named sample.html, and returns the contents of that file in the HTTP response message.
In summary, we have:
- URL in browser get divided into HOST and RESOURCE
- Browser opens HTTP connection to HOST and sends “GET” requestfor RESOURCE
- Server finds the file that corresponds to RESOURCE, and responds with HTTP response, containing file contents.
By contrast, a web app is some code that the web server runs in response to a GET request to calculate the response that will be sent back.
Perhaps the most familiar and commonly used “web app” is Google Search. Consider this URL:
Let’s break this URL
https://www.google.com/search?q=pupplies down into its pieces:
- The HOST in this URL is www.google.com, and the RESOURCE is
- The part that comes after the question mark (
?) contains parameter values. In general, its a list of key/value pairs.
- In this particular URL, there is only one key/value pair. The key is
qand the value is
In response the Google web server runs a computation that:
- does a search on the term
- collects results in some data structure
- converts that data structure into the HTML for a formatted web page of those results
- sends back that computed web page
Typically, though, a user doesn’t interact with Google by typing in a query such as that one. It would be more typical to go to http://google.com, or a Google Search bar, or app on their phone, then type
puppies into the search box and press return.
In the case of the Google.com home page at http://google.com, the HTML for that page is coded so that whatever you type into the search box produces a URL that has
q=puppies in it. In general, any web page or app that interacts with a web app via GET requests will have code to
- gather input from the user (through text boxes, check boxes, radio buttons, etc.)
- put that input into the appropriate parameters to the GET request
- send that along with the GET request to the server.
A web app:
- receives a HTTP GET request message or any of several other kinds of request that we’ll discuss in a moment), along with its parameters,
- computes the response that goes back (in HTML, or whatever other format may be needed) based on the requested resource and its parameters
- sends that response back to the requester in an HTTP response message
GET request is only one kind of request that can be made to a webapp. There are a variety of others, the most important one being
POST. A complete list can be found in the specification for the HTTP protocol, here:
We’ll cover those other kinds of requests, and the difference between
POST in another article.
- For now, if you want to learn more, see: “Get vs. Post” http://blog.teamtreehouse.com/the-definitive-guide-to-get-vs-post
- Also see the article about REST