This series of articles is a compilation of the notes I gathered during my programming bootcamp at Green Fox Academy, last year.
The nine articles of this series are designed to give you a general overview of everything you need to know to enter the world of IT, especially in a point of view of a backend developer and, sometimes, with specificities of the Java programming language. Things are not explained in depth, rather they are a starting point for further exploration on your own. Enjoy!
Parts of an URL
A basic URL is made up of 3 parts:
- Protocol / scheme — declares how the browser should communicate with a web server. The most common is HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure)
- Domain name — unique reference that identifies a website on the internet (identifies the host that holds the resource)
- Path — identifies the specific resource in the host that the web client wants to access
A complex URL might include:
- Protocol (HTTP)
- Domain (host) name
TCP/IP is a family of communication protocols used to connect computer systems in a network. It is named after two of the protocols in the family: Transmission Control Protocol (TCP) and Internet Protocol (IP). Hypertext Transfer Protocol (HTTP) is NOT really member of the TCP/IP family, but relies on TCP/IP as underlying data transport protocols almost exclusively.
Internet Protocol (IP)
IP is a network-layer protocol that provides a connectionless data transmission service that is used by TCP. Data is transmitted link by link; an end-to-end connection is never set up during the call. The unit of data transmission is the datagram.
Transmission Control Protocol (TCP)
TCP is a transport-layer protocol that provides a reliable, full duplex, connection-oriented data transmission service. Most Internet applications use TCP.
Hypertext Transfer Protocol (HTTP)
HTTP is an application-layer protocol that is used for distributed, collaborative, hypermedia information systems. HTTP is the protocol used between web clients and web servers.
HTTP Requests / Responses
The correct format for HTTP requests and responses depends on the version of the HTTP protocol (or HTTP specification) that is used by the client and by the server.
The versions of the HTTP protocol (or “HTTP versions”) commonly used on the Internet are HTTP/1.0, which is an earlier protocol including fewer functions, and HTTP/1.1, which is a later protocol including more functions. The client and server might use different versions of the HTTP protocol. Both client and server must state the HTTP version of their request or response in the first line of their message.
A correctly composed HTTP request contains the following elements:
1. A request line
2. A series of HTTP headers, or header fields
3. A message body, if needed
- Request line
The request line is the first line in the request message. It consists of at least three items:
a. A method (http verb) — The method is a one-word command that tells the server what it should do with the resource.
b. The path component of the URL for the request — the path identifies the resource on the server.
c. The HTTP version number, showing the HTTP specification to which the client has tried to make the message comply
Example: GET /software/htp/cics/index.html HTTP/1.1
A request line might contain some additional items:
·A query string — this provides a string of information that the resource can use for some purpose. It follows the path and is preceded by a question mark.
· Scheme and host components of the URL
2. HTTP headers
HTTP headers are written on a message to provide the recipient with information about the message, the sender, and the way in which the sender wants to communicate with the recipient.
The HTTP headers for a client’s request contain information that a server can use to decide how to respond to the request.
Accept-Language: fr, de
If-Modified-Since: Fri, 10 Dec 2004 11:22:13 GMT
3. Message body
The body content of any HTTP message can be referred to as a message body or entity body. Technically, the entity body is the actual content of the message. Message bodies are appropriate for some request methods and inappropriate for others. For example, a request with the POST method, which sends input data to the server, has a message body containing the data. A request with the GET method, which asks the server to send a resource, does not have a message body.
An HTTP response contains:
1. A status / response line
2. A series of HTTP headers
3. A message body, which is usually needed
1. Status line
The status line is the first line in the response message. It consists of three items:
a. The HTTP version number, showing the HTTP specification to which the server has tried to make the message comply
b. A status code, which is a three-digit number indicating the result of the request
c. A reason phrase, also known as status text, which is human-readable text and summarises the meaning of the status code
Example of a response line: HTTP/1.1 200 OK
2. HTTP headers
The HTTP headers for a server’s response contain information that a client can use to find out more about the response, and about the server that sent it. This information can assist the client with displaying the response to a user, with storing (or caching) the response for future use, and with making further requests to the server now or in the future. In the case of an unsuccessful request, headers can be used to tell the client what it must do to complete its request successfully.
3. Message body
Message bodies are used for most responses. For a response to a successful request, the message body contains either the resource requested by the client, or some information about the status of the action requested by the client. For a response to an unsuccessful request, the message body might provide further information about the reasons for the error, or about some action the client needs to take to complete the request successfully.
They are extensions of the URL that are used to help define specific content or actions based on the data being passed. To append query params to the end of a URL, a ‘?’ is added followed immediately by a query parameter. To add multiple parameters, an ‘&’ is added in between each.
Status codes are issued by a server in response to a client’s request made to the server. The first digit of the status code specifies one of five standard classes of responses. The message phrases shown are typical, but any human-readable alternative may be provided.
· 1xx (Informational): The request was received, continuing process
· 2xx (Successful): The request was successfully received, understood, and accepted
· 3xx (Redirection): Further action needs to be taken in order to complete the request
· 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
· 5xx (Server Error): The server failed to fulfill an apparently valid request
Most common status codes
200 — OK / 201 — Created / 202 — Accepted
301- Moved Permanently / 302 — Found / 304 — Not Modified
400 — Bad Request / 401 — Unauthorized / 403 — Forbidden / 404 — Not Found
500 — Internal Server Error / 503 — Service Unavailable
Representational State Transfer (REST) is an architectural style for distributed hypermedia systems, devised by Roy Fielding in his PhD dissertation (2000). Simply put, an endpoint is one end of a communication channel. When an API interacts with another system, the touchpoints of this communication are considered endpoints. For APIs, an endpoint can include a URL of a server or service. Each endpoint is the location from which APIs can access the resources they need to carry out their function.
A REST (REpresentational State Transfer) API allows the server to transfer to the client a representation of the state of the requested resource. It follows six constraints:
- Uniform Interface
- Layered System
- Code on demand (optional)
GET: requests a representation of the specified resource. Requests using GET should only retrieve data.
HEAD: it asks for a response identical to that of a GET request, but without the response body.
POST: used to submit an entity to the specified resource, often causing a change in state or side effects on the server.
PUT: replaces all current representations of the target resource with the request payload.
DELETE: deletes the specified resource.
CONNECT: establishes a tunnel to the server identified by the target resource.
OPTIONS: it is used to describe the communication options for the target resource.
TRACE: performs a message loop-back test along the path to the target resource.
PATCH: it is used to apply partial modifications to a resource.