POST versus GET
As far as I’m aware POST requests are also capable of being used to send much more data than a GET request anyway and the data sent to the server doesn’t need to show up in the URL like a GET request does. Because a GET request doesn’t rely on information being changed, they can be Cached, which means the server stores a pre-calculated copy of the page to be sent to users instead of running any complicated rendering code each time someone requests the page. Because POST requests are all about sending data to a server with the intent of changing the server, POST requests cannot be cached.
What is a server?
A Server in one sense is simply a computer configured to send information to other computers. The key difference between a server and a client computer is what is done with the data.
The other main request is the POST request. This request sends data to the server with the intention that the server will store that data in some useful way. It is possible for the server to store data sent to the server using a GET request, but this can usually lead to problems.
HTTP Response Headers and Codes
Responses come with some general information and headers as well. First there’s a response code, which gives a general indication as to how the request went. Three common ones are: 200: OK, 404: Not Found and 500: Server Error. The number can be used by programs to quickly identify how things went where the text gives a human an easy indication. Headers generally contain similar information as request headers but in the other way around. For example the Server header gives the client some information about what server software generated the response.
With the web, the primary way servers and clients talk to each other is using HTTP requests. A client will usually send a GET request to the server, asking for a particular URL. Then the server will send back a response. If the URL is valid and nothing else goes wrong, the client will receive the data they requested, if something is wrong, they will receive an error of some kind.
Why Validate: Get the data you ask for
The second biggest and often more obvious reason is to avoid making a mess of the data and causing bugs. If you need someone’s name in a form and they don’t provide one, at best this will result in a weird looking profile output, but usually it would cause bugs to happen.
Security is the biggest reason to validate input, it is possible for malicious code to be inserted into a web page if a user sends in html code that the website redisplays.
What is Validation?
Making sure the information you need is the information you get. That’s what validating input is. So exactly how to validate input depends on the situation. It should always be done on the server regardless of any checks done on the client.
Validation is boring, so remember to do it!
Validating input is not the easiest thing to do and it’s one of the most time consuming things to do so it’s especially important to make an effort to program it in.
Template Engine: Jinja2
HTML template engines such as jinja2 provide a very clean way to describe the overall layout of a web page and then fill it with content. The templates provide the abstraction, while the specific content sent in to the template render for each request makes things interesting.
To revise on the concept of abstraction: it’s the skill of noticing similarities and repetitive elements and separating them from specific uses so that less code needs to be maintained. It is possible to go too far into abstraction and end up making the code worse, so it’s still more of an art form than a hard science.
Templates and Debugging
In addition to making it easier to maintain a website. Templates also make debugging easier. Because if you make a mistake with one of the templates it has a tendency to break all of the pages in some way, which makes it less subtle that things are wrong. The net result is even less time spent working on the templates.
On top of that templates often provide template inheritance, meaning common elements no longer have to be retyped up in each template, but only one parent template that all the other templates inherit from. This is very similar to how css files allow style information to be separated from the structure of a page and provides the same advantage: change just the parent template and the children templates change too without any further work from you the programmer.
3: What I learned from Intro to jQuery
I still don’t know a huge amount about web development, I don’t yet know how to manipulate the DOM without a helper library and it’s probably a good idea that I do that at some point. But what I did learn was that jQuery is a small library that I can use to make it far better to work with the DOM. I know how to select elements, add elements, remove elements, modify elements (add classes to them so they get styled). I’m reasonably confident that I know all the basics of jQuery to the point I can create a useful web application and that I can go find out anything else if I want to get particularly fancy. On top of that I learned of the existence of d3 (data driven documents), which is very similar to jQuery and have begun studying that. It’s good to have options.
5: d3js - Data Driven Documents (extra 1 of 2)
4: What I learned from Intro to AJAX
I’ve heard about AJAX before but never really known what it is exactly. Turns out it isn’t anything exactly. AJAX is the name that refers to a bunch of programming techniques used by developers to get their websites updating their data without requiring a page refresh. This is exactly what I wanted to hear as the web applications I want to make basically demand that functionality. Aside from that I didn’t look hugely into the AJAX presented in the course as it wasn’t specifically what I was looking for, but I did find d3js at some point when exploring these courses…
1: Overview of what I’m trying to achieve
6: Mozilla Developer Network - MDN (extra 2 of 2)
\& testing <b>bold</b>