Understanding URIs, URLs, URNs, Other Fundamentals
Response is what the server returns back to the client (client is the machine making the request). This typically not only includes the resource but also may include: status codes, headers, cookies, etc
Resource is a single web object like a webpages source code, image, video, pdf, css file. Resources like a webpages can reference other resources like images that should be part of a single render (render is the intended final result of an action)
Action is a process that happens on a server which is meant to trigger a service and/or return a resource. Typically you'll always return a resource when an action is triggered to let the client know the service has been triggered. This could be as simple as returning plain text, or triggering sophisticated code which runs on multiple server.
GET is a type of request your browser makes when it wants to fetch something from a server. It's like asking, "Hey server, can you give me this thing?" GET requests are typically used when you're just trying to view or retrieve information, not change anything on the server. When you type a URL into your browser and hit enter, that's usually a GET request.
For example, when you visit https://example.com/page.html, your browser is making a GET request for the page.html file.
POST is another type of request, but it's used when you want to send data to the server to be processed. It's like saying, "Hey server, here's some information, please do something with it." POST requests are often used when submitting forms or uploading files. They can change data on the server. They however often times also return a response for example to redirect you to another webpage or to inform you what is going on after you've submitted data e.g. "you've logged in"
Headers Headers are extra bits of information sent along with requests and responses between web browsers and servers. They're like labels on a package, giving details about what's inside and how to handle it. Headers can tell you things like what type of content is being sent, what server software is being used, or how long to keep the content in memory. Both the client (like your web browser) and the server add headers to their messages.
Example of headers shown below, noticed with the -I flag set on curl we do not see the resource of the website only the headers. These are headers on a website that is running the httpd/apache daemon with the PHP module installed into httpd. (X-Powered-By) was added by the PHP module in Apache.
$ curl -I example.com
HTTP/1.1 200 OK
Date: Fri, 12 Jul 2024 04:20:39 GMT
Server: Apache/2.4.57 (Rocky Linux)
X-Powered-By: PHP/8.0.30
Content-Type: text/html; charset=UTF-8
URI (Uniform Resource Identifier) identifies a specific resource by either by name or location (name which is a URN) or (location which is a URL). When identifying by name we are looking for a specific resource recognized by a widely recognized standard such as a ISBNs for books. When identifying by location we are trying to get a resource from a specific location using a url, such as a web-servers web-page/content over a network (even if that network is your single machine looping back to itself)
- URN (Uniform Resource Name) by name: URNs are persistent, location-independent identifiers. An example is a DOI (Digital Object Identifier) would be this 10.1109/4236.793464 this does not give us the address of the document but rather specifies a specific document; like an ISBN is to a book which there could be multiple copies in many locations
- URL (Uniform Resource Locator) by location: An example would be https://google.com/images OR http://example.com/charts.pdf OR ssh://
This email address is being protected from spambots. You need JavaScript enabled to view it. :22- The URL can be seen as both locator and location its' a locator insofar as it specifies how to find an object i.e. giving your web-browser or ssh daemon the necessary information to run the commands needed to get to the resource; and the url specifies the location of the resource. i.e. its' an address of a resource like a web-page or image though whatever resource is there might change; its' really just a location and how to get to that location.
- The schema of a URL is scheme://user:password@host:port/path
- Dependent on the web-framework, web server daemon, and/or request type the scheme might even include things after /path scheme://user:password@host:port/path?query#fragment
- Request types include GET and POST
URLs are primarily to identify and locate resources; though they can also be used to trigger actions.
- Uniform: in that the whole web uses this standard
- Resource: Anything that can be accessed from the web
- Locator: The purpose of a URL is to get you to the resource
Web Daemon e.g. httpd/nginx/apache is a service running on a machine which handles requests and sends back a response. Unless suppressed these daemons add "headers" to the request information.
Sometimes web daemons are built-into web frame works like Django and Flask, often times just for development use, and not for production (production the live system; think opposite of testing i.e. the actual product)
How rendering on a web browser is done:
When looking at web pages it is not usually as simple as url -> request -> response
- You put in a URL into the web browser
- Networking happens (not important right now)
- The web server daemon (like Django/Apache) routes to a specific html/php/python script etc
- If there is a web-frame work like Django or PHP the route might point to a file which takes an action and/or generates a resource. It might even start generating some headers to be put into the response along with the resource.
- The web-server then generates a response and includes its' own headers (status code, etc) along with the resource (possibly generated by script in step 3) back to the web-browser
- Web browsers will typically start to render the webpage even if it hasn't gathered all the resources.
- If there are images, css files, etc referenced in the response, the clients web-browser will continue by itself making requests to the web browser for those resources; using the paths/urls referenced in the original resource
- The web browser will render the webpage as it and if there is anything dynamical about the webpage the web browser will continue making requests.
