On The Road To Professional Web Development | HTTP, HTTPS, & APIs

*The objective of this article is to prepare for a technical interview. To succeed (1) we must be technically proficient, and (2) we must be capable of communicating our proficiency effectively.

In this post, we’ll first become conversationally fluent on HTTP, HTTPS, and APIs. Next we’ll run drills to get comfortable using these technologies in practical ways. Finally we’ll finish the discussion with a curated list of (reportedly) common interview questions.

This post is part of a series on becoming a professional web developer — click here to navigate to the table of contents*

Part I: HTTP, HTTPS, and APIs

How Difficult Are They To Master?

These technologies tread the line between theory and practice. To fully understand the value of HTTP, readers should have a basic understanding of how the internet works. Secure HTTP, or HTTPS, requires an understanding of encryption. APIs are developer-defined pieces of software that are usually customized to dictate how users can interact with a server-side resource. Requests to the API come in the form of HTTP, so understanding the underlying technology is critical to successful API design.

What Are They?

HTTP is the protocol used for a browser (client) to request an action from a server. HTTP requests are just plaintext. HTTPS is the same as HTTP, but encrypted. HTTP can be used to request all kinds of information or actions — it’s highly flexible. Since HTTP requests are so flexible, they could easily be misused (maliciously or accidentally). That’s where APIs come in. Unlike HTTP, which is a universal standard, APIs are developer-defined. They specify how to properly interact with server-side resources, and prevent misuse by rejecting malformed HTTP requests.

What Are These Technologies To Developers?

• HTTP content security policies help defend against Cross-Site Scripting (XSS) attacks and data-injection attacks
• HTTPS ensures HTTP data is secure in transit
• Existing HTTP standards such as status response codes enforce best practices and help us avoid re-inventing the wheel
• Good APIs limit the ways clients interact with servers (which they do via HTTP). This makes it easy to document how to properly interact with server-side resources, and also adds a layer of security by rejecting bad requests

Where Did They Come From?

A long time ago (circa 1945), Vannevar Bush published an essay describing a hypothetical machine called a “memex”. It was a machine capable of accessing information by reference — it’s the kind of behavior we expect today when we click on a link, but this concept was invented before computers existed. In a time where people relied on rolodexes and the Dewey Decimal System to access information, the memex was way ahead of its time.

The terms hyperlink and hypertext were coined several years later (in 1963) by Ted Nelson, but it wasn’t until 1989 that Tim Berners-Lee and his team at CERN invented the original implementation of HTTP alongside their invention of the World Wide Web.

HTTP 2 came about in 2015, and remains backwards compatible with HTTP 1.x implementations. HTTPS was invented in 1994 but only as recently as 2018 did browsers start automatically flagging non-HTTPS sites as unsecured.

APIs aren’t protocols like HTTP or HTTPS — loosely speaking APIs are design choices made by developers — the “history of APIs” isn’t exactly an easy topic of discussion. But there are several common strategies employed in API design, the most popular of which is REST. REST APIs were originally defined by Roy Fielding in his PhD dissertation at the turn of the millennium. There were other API design strategies, but most faded in popularity compared to REST until Facebook’s 2015 release of GraphQL. We’ll see how this plays out over the next several years, but GraphQL appears to be gaining widespread acceptance that may actually give RESTful API designs a run for their money.

What Terminology Comes Up When Discussing These Technologies?

• Application Programming Interface (API): a software interface designed to mediate information exchanged between programs. “We define interfaces (i.e. APIs) to make interactions between programs less error-prone and more secure”
• Certificate Authority (CA): certificates are used to verify the site you’re on is ‘the real one’. A CA is trusted third party that verifies a certificate is authentic. “If you’ve ever built a website from scratch, you’ll probably notice the browser gets upset that your site isn’t secure. Thanks to free CA’s like Let’s Encrypt, our sites can easily use HTTPS URLs and our browsers will identify our site as secure”
• Client-Server Model: a design approach separating responsibilities of requestors (clients) from requestees (servers). “HTTP and REST APIs follow a client-server style division of responsibility”
• Content Security Policy (CSP) Directives: HTTP headers enforcing best-practices that improve security and mitigate the risk of attacks. “HSTS (HTTP Strict Transport Security) is a CSP header specifying that all content must be loaded with HTTPS. This greatly reduces the risk of packet sniffing attacks”
• Cross-Origin Resource Sharing (CORS): a mechanism that allows restricted resources on a web page to be requested from a non-origin domain. “By default, HTTP enforces a Same Origin Policy (SOP). Others may want to use some of our images (or other resources) as embeds in their own sites, but SOP prevents this unless instructed otherwise. CORS lets us add exceptions to the SOP as we see fit”
• Graph Query Language (GraphQL): an alternative to RESTful API design. “Facebook developed GraphQL in 2012 and released it publicly in 2015. It’s gaining popularity — for example GitHub offers both a REST API and a GraphQL API. GitHub’s GraphQL Explorer tool lets us try it out in our browser!”
• HTTP Request Methods: the nine essential commands we can invoke using HTTP. “methods include: GET, HEAD, POST, PUT, DELETE, OPTIONS, CONNECT, TRACE, PATCH”
• HTTP Secure (HTTPS): HTTP encrypted using TLS. “Here’s an excellent visualization of the TLS handshake process used by HTTPS”
• HTTP Status Response Codes: status codes that help us keep track of whether HTTP communications succeeded or failed. “We can define our own or use the standardized codes listed here (or both)”
• HyperText Transfer Protocol (HTTP): the protocol built atop TCP/IP to fetch data using GET, POST, and a few other similar operations. “HTTP ”
• Internet Protocol (IP): a protocol to send packets of information from one device to another. “IP is like the postal service of the internet”
• Media Access Control (MAC) Address: a unique identifier for all network interface devices. “Also known as a hardware address or physical address, MAC addresses include the manufacturer’s unique organization ID. This makes it easy to enforce MAC address uniqueness within companies (and between competing companies)”
• Message Authentication Code (MAC): a tag. “a short piece of information used to authenticate a message”
• Protocol: a system of rules that defines how data is exchanged. “The internet works as well as it does mainly thanks to everyone agreeing on certain standards (protocols including IP and HTTP)”
• Representational State Transfer (REST): guidelines for defining a ‘good’ API. “APIs that are designed to be RESTful don’t have strict rules regarding implementation but follow six architectural guidelines”
• Request-Response Cycle: a detailed look at how communications flow between clients and servers. “Any communication requiring acknowledgements or responses between the client and the server can be described in terms of a request-response cycle”
• Simple Object Access Protocol (SOAP): an API style commonly considered to be an alternative to REST. “SOAP is largely outdated in favor of REST or, much more recently, GraphQL-style APIs”
• SSL/TLS (Secure Sockets Layer / Transport Layer Security): while SSL and TLS serve the same essential purpose (encrypting communications), TLS made SSL entirely obsolete. “HTTPS is nothing more than HTTP encrypted using TLS”
• Stateless System: stateless is a synonym for memoryless — such systems don’t offer builtin ways to use previous requests to influence new requests. “HTTP is stateless but not sessionless”
• Transmission Control Protocol (TCP): information tucked away inside the data payload of IP packets in order to help keep track of whether or not all the packets arrived at the destination. “If IP is thought of as the postal service of the internet, TCP serves the same purpose as the tracking info for each delivery (packet)”
• Uniform Resource Identifier (URI): a string that unambiguously identifies a particular resource. “The URI for the post you’re currently reading is displayed in your browser’s address bar above”
• Uniform Resource Locator (URL): a web address. “The URL for this site is medium.com”

Part II: Using HTTP, HTTPS, and APIs

Part II focuses on using these technologies effectively. APIs will likely be our bread-and-butter for much of our careers as web developers, but to understand them fully, we’ll first need to study some underlying technologies.

• Understand how the internet works, and the basics of HTTP (Khan Academy here, here, and here) (CrashCourse here, here, and here)
• Understand the difference between HTTP1 and HTTP2
• Understand HTTP and HTTPS
• Understand client-side web APIs
• Read this guide to best practices for API design
• See this list that keeps track of popular APIs (including those for well known sites like XKCD and Medium)

Part III: HTTP, HTTPS, and API Interview Questions

The goal of Part III is to summarize interview questions from across on the web. Questions have been paraphrased to avoid duplicate entries. Drill on these while practicing for the interview, and don’t hesitate to Google solutions.

• compare GET to PUT
• compare HTTP 1 to HTTP 2
• compare PUT to POST
• compare PUT to POST
• compare REST to SOAP
• compare the reliability of TCP/IP to the reliability of UDP/IP
• discuss best practices for URI representation in REST services
• discuss caching
• discuss CORS
• discuss curl
• discuss DNS spoofing
• discuss ETags
• discuss GraphQL
• discuss HEAD
• discuss HTTP
• discuss HTTP caching
• discuss HTTP client libraries
• discuss HTTP content negotiation
• discuss HTTP header fields
• discuss HTTP request messages
• discuss HTTP response code 100
• discuss HTTP response code 200
• discuss HTTP response code 201
• discuss HTTP response code 300
• discuss HTTP response code 400
• discuss HTTP response code 401
• discuss HTTP response code 405
• discuss HTTP response code 408
• discuss HTTP response code 409
• discuss HTTP response code 500
• discuss HTTP responses
• discuss HTTP security
• discuss HTTP session state
• discuss HTTP verbs
• discuss HTTPS
• discuss HTTPS certificates
• discuss idempotent
• discuss idempotent methods
• discuss long polling
• discuss OPTIONS
• discuss persistent connections
• discuss POST
• discuss query languages
• discuss resource representation
• discuss REST
• discuss rest addressing
• discuss REST API testing
• discuss REST API usage limitations
• discuss REST consoles
• discuss REST messaging
• discuss REST payloads
• discuss REST resources
• discuss statelessness
• discuss the API gateway design pattern
• discuss the OSI layer of HTTP
• discuss the OSI layer of IP
• discuss URI
• discuss web service security concerns
• list HTTP methods
• list HTTP status codes
• list tools for REST API development and testing

Closing Thoughts

I hope you’ve enjoyed this post as much as I enjoyed writing it. If you have thoughts you’d like to share, your editorial suggestions are always welcome. This post is part of a series on becoming a professional web developer. If you’d like to see more content like this, please click here to navigate to the table of contents.