Web

/ˌɛf-ti-ˈpi/

n. “Moving files, one connection at a time.”

FTP, short for File Transfer Protocol, is one of the oldest network protocols designed to transfer files between a client and a server over a TCP/IP network. Dating back to the 1970s, it established a standardized way for computers to send, receive, and manage files remotely, long before cloud storage and modern APIs existed.

Using FTP, users can upload files to a server, download files from it, and even manage directories. Traditional FTP requires authentication with a username and password, although anonymous access is sometimes allowed. Secure variants like SFTP and FTPS encrypt data in transit, addressing the original protocol’s lack of confidentiality.

A basic FTP session involves connecting to a server on port 21, issuing commands like LIST, RETR, and STOR, and transferring data over a separate data connection. While this architecture works, it can be blocked by firewalls or NAT devices, leading to the development of passive FTP and more secure alternatives.

Despite its age, FTP remains in use for legacy systems, website deployments, and certain enterprise workflows. Modern developers may prefer HTTP or SFTP for file transfers, but understanding FTP provides historical context for networked file sharing, permissions, and protocol design.

Example usage: uploading website assets to a hosting server, downloading datasets from a remote repository, or syncing files between office systems. FTP clients like FileZilla, Cyberduck, and command-line tools remain widely deployed, proving the protocol’s resilience and longevity.

FTP does not inherently encrypt credentials or files. When security matters, combine it with secure tunnels like SSH or use its secure alternatives. Its legacy, however, lives on as a foundational protocol that influenced modern file-sharing standards.

/ˌɛks-ɛm-ɛl-ˌhɪt-ti-pi rɪˈkwɛst/

n. “Old school, but still gets the job done.”

XMLHttpRequest, often abbreviated as XHR, is a JavaScript API that enables web browsers to send HTTP requests to servers and receive responses without needing to reload the entire page. Introduced in the early 2000s, it became the backbone of what we now call AJAX (Asynchronous JavaScript and XML), allowing dynamic updates and interactive web applications.

Despite the name, XMLHttpRequest is not limited to XML. It can handle JSON, plain text, HTML, or any type of response. A typical request looks like:

const xhr = new XMLHttpRequest();
xhr.open('GET', '/api/data', true);
xhr.onload = function() {
  if (xhr.status === 200) {
    console.log(JSON.parse(xhr.responseText));
  }
};
xhr.send(); 

Here, open sets up the HTTP method and URL, onload handles the response, and send dispatches the request. Errors and progress events can also be monitored using onerror and onprogress handlers, providing fine-grained control over network communication.

XMLHttpRequest has largely been superseded by the fetch API in modern development, which offers a cleaner, promise-based approach and improved readability. However, XHR remains relevant for legacy applications, older browsers, and cases where fine-grained event handling or synchronous requests are needed.

In practical terms, XMLHttpRequest enabled a shift from static, page-reloading websites to dynamic web apps, laying the foundation for single-page applications (SPAs) and real-time data updates that we take for granted today. Its design influenced modern APIs like fetch, and understanding XHR is essential for maintaining or interfacing with older web systems.

/fɛtʃ/

v. “Go get it — straight from the source.”

fetch is a modern JavaScript API for making network requests, replacing older mechanisms like XMLHttpRequest. It provides a clean, promise-based interface to request resources such as HTML, JSON, or binary data from servers, making asynchronous operations much more readable and manageable.

At its simplest, fetch('https://api.example.com/data') sends a GET request to the specified URL and returns a Promise that resolves to a Response object. This response can then be converted into JSON via response.json() or plain text via response.text(). For example:

fetch('https://api.example.com/users')
  .then(response => response.json())
  .then(data => console.log(data)); 

fetch supports all standard HTTP methods: GET, POST, PUT, PATCH, DELETE, etc., and allows customization through headers, body content, credentials, and mode (such as cors or no-cors). This flexibility makes it ideal for interacting with REST APIs or modern web services.

Unlike curl or older XMLHttpRequest approaches, fetch leverages JavaScript Promises, which allows for straightforward chaining, error handling, and asynchronous logic without the callback hell that plagued older methods. Errors like network failures or server rejections can be caught cleanly with .catch().

fetch also supports streaming responses, enabling partial processing of data as it arrives, which is useful for large files, live feeds, or progressive data consumption. Combined with JSON parsing and modern ES6 features, it provides a robust, readable way to interact with the network directly from the browser or JavaScript runtime environments like Node.js.

In practice, using fetch can simplify web application development, improve maintainability of API calls, and allow developers to handle network operations in a predictable, elegant way. It has become the default method for network requests in modern front-end development, and understanding it is crucial for any developer working with the web today.

/kərl/

n. “Talk to the internet without a browser.”

cURL is a command-line tool and library (libcurl) for transferring data with URLs. It supports a vast array of protocols, including HTTP, HTTPS, FTP, SMTP, and more, making it a Swiss Army knife for internet communication and scripting.

At its core, cURL allows users to send requests to remote servers and retrieve responses. For example, curl https://example.com fetches the HTML of a web page, while curl -X POST -d "name=Chris" https://api.example.com/users can submit data to an API endpoint. This makes it invaluable for testing, automation, and interacting with REST APIs.

cURL is also scriptable and works in batch operations, allowing repeated requests or data fetching without manual intervention. It can handle authentication headers, cookies, and SSL certificates, bridging the gap between human-readable browsing and programmatic interactions.

Developers often pair cURL with JSON or XML responses to automate tasks, test endpoints, or debug network interactions. For example, extracting user data from an API or sending log files to a remote server can be accomplished seamlessly.

While simple in its basic form, cURL is powerful enough to act as a full-fledged HTTP client. It is available on most operating systems, embedded in scripts, CI/CD pipelines, and even used by SaaS platforms to test and integrate external services.

Understanding cURL equips anyone dealing with networking, web development, or automated workflows to interact with the internet directly, bypassing browsers and GUIs, providing precision and reproducibility for testing, troubleshooting, and data transfer.

/krʊd/

n. “Create, Read, Update, Delete — the alphabet of persistent data.”

CRUD is an acronym representing the four fundamental operations that can be performed on persistent storage or resources in a database or application: Create, Read, Update, and Delete. These operations form the backbone of most software systems, allowing users and applications to manage data effectively.

In a REST context, CRUD operations map naturally to HTTP methods: POST for Create, GET for Read, PUT or PATCH for Update, and DELETE for Delete. This alignment simplifies API design and ensures that client-server interactions remain consistent and predictable.

For example, consider a CRUD interface for managing a contacts database. Create adds a new contact, Read retrieves contact details, Update modifies an existing contact’s information, and Delete removes a contact from the system. These four operations cover nearly all use cases for data management.

CRUD is not limited to relational databases; it applies to document stores, key-value stores, cloud services, and even local file systems. When combined with REST principles, CRUD provides a universal language for designing scalable and maintainable APIs.

Understanding CRUD is essential for developers, system architects, and anyone designing interactive applications. It provides a conceptual framework that ensures every data interaction has a clear purpose, promotes consistency, and reduces the likelihood of unintended side effects.

Many modern tools, frameworks, and platforms provide CRUD scaffolding or generators, allowing developers to quickly implement data management functionality while following best practices. Whether in web development, mobile apps, or enterprise systems, CRUD remains the fundamental model for interacting with data.

In short, CRUD is simple, pervasive, and indispensable: the unspoken grammar of data operations that powers everything from tiny scripts to massive cloud services.

/rɛst/

n. “Architect it once, call it anywhere.”

REST, short for Representational State Transfer, is an architectural style for designing networked applications. It emphasizes a stateless client-server communication model where resources are identified by URIs, and interactions are carried out using standard HTTP methods like GET, POST, PUT, PATCH, and DELETE.

In a RESTful system, each resource can be represented in multiple formats such as JSON, XML, or HTML. The server provides the representation, and the client manipulates it using HTTP verbs. REST is stateless: every request contains all information necessary for the server to process it, which improves scalability and simplifies reliability across distributed systems.

For example, a REST API might expose a resource at /users/123. A GET request retrieves the user, a PUT request updates the user, a PATCH request partially modifies the user, and a DELETE request removes the user.

REST is not a protocol or standard — it is a style of designing services. Constraints like uniform interfaces, stateless interactions, cacheable responses, layered system architecture, and code-on-demand (optional) guide developers to build simple, scalable, and flexible APIs. Adhering to these principles makes applications easier to maintain and allows clients written in different languages or platforms to interact seamlessly.

REST powers much of the modern web. Social media platforms, SaaS applications, cloud services like IaaS, PaaS, and microservices architectures often expose RESTful APIs. Its design encourages clear separation of concerns: the server manages resources, while the client handles presentation and state transitions.

Consider a developer building a dashboard that aggregates user data from multiple services. By leveraging REST APIs, they can fetch JSON representations from different servers, combine the data, and display a unified interface — all without needing specialized protocols or complex bindings.

While REST is widely used, alternatives like GraphQL or gRPC exist, offering different trade-offs in flexibility and efficiency. Nevertheless, REST remains a cornerstone of web architecture, emphasizing simplicity, statelessness, and universal compatibility through standardized HTTP mechanisms.

/dɪ-ˈliːt/

n. “Gone. No take-backs.”

DELETE is an HTTP request method used to remove a resource from a server. When a client issues a DELETE request to a specific URI, the server is instructed to permanently remove that resource, or at least mark it as deleted depending on implementation. Unlike PATCH or PUT, which modify resources, DELETE is purely destructive — its purpose is removal.

For example, sending a DELETE request to /users/123 would instruct the server to remove the user with ID 123 from its database. The operation should be idempotent: sending the same DELETE request multiple times should have the same effect as sending it once, meaning that after the first deletion, subsequent requests typically result in a 404 Not Found or equivalent response.

In RESTful APIs, DELETE is used alongside GET, POST, PUT, and PATCH to provide full CRUD (Create, Read, Update, Delete) capabilities. Its idempotency is a key design principle: clients can retry DELETE safely without risking duplicate deletions.

Security considerations are critical when implementing DELETE. Servers must ensure that the client is authenticated and authorized to delete the resource. Logging deletions, requiring confirmation, or using soft deletes (marking a resource as inactive rather than removing it entirely) are common strategies to prevent accidental data loss.

In practical use, DELETE enables administrators to manage resources, clean up outdated data, or remove sensitive information. For instance, a SaaS platform may allow users to delete their accounts, or an application may remove obsolete entries from a database. When combined with TLS encryption, DELETE requests can be securely transmitted over the network.

Overall, DELETE is a fundamental web method for removal operations. While simple in concept, proper implementation ensures consistency, prevents unintended data loss, and maintains the integrity of modern APIs and web applications.

/pætʃ/

n. “Fix it, tweak it, change just what’s needed.”

PATCH is an HTTP request method used to apply partial modifications to a resource on a server. Unlike PUT, which replaces the entire resource, PATCH allows clients to send only the fields or sections that need updating. This makes PATCH ideal for efficient updates where only a small portion of a resource has changed.

For example, if a user profile exists at /users/123 and only the email address needs to be updated, a PATCH request can include just the new email field rather than sending the entire profile data. This reduces bandwidth usage and lowers the risk of accidentally overwriting unrelated fields.

In RESTful APIs, PATCH is used alongside PUT, POST, GET, and DELETE to provide a complete CRUD toolkit. While PUT is idempotent (repeating the request results in the same state), PATCH can be non-idempotent depending on how the server applies the changes, so developers should implement it carefully.

Common uses of PATCH include updating user preferences, adjusting configurations, or modifying specific fields in a document without touching the rest. API designers often combine PATCH with JSON or XML payloads specifying the exact keys or paths to modify.

Security considerations include authenticating the client, validating input data, and ensuring authorization for partial updates. Encryption via TLS is recommended to protect sensitive data in transit. Proper implementation prevents unintended changes or corruption of the resource.

In essence, PATCH gives developers surgical precision for resource updates. It is a flexible tool that complements PUT and POST, allowing modern web applications, SaaS platforms, and APIs to operate efficiently, minimize errors, and maintain data integrity while handling incremental changes.

/pʊt/

n. “Replace it, overwrite it, make it exactly this.”

PUT is an HTTP request method used to update or replace a resource on a server with the data provided in the request body. Unlike POST, which typically creates a new resource or triggers an action, PUT is idempotent — sending the same request multiple times results in the same state on the server without creating duplicates.

For example, if a web application manages user profiles at /users/123, sending a PUT request with updated data such as name, email, or preferences will replace the existing profile with the new content. Repeating this request does not duplicate the profile — it simply enforces the specified state.

In RESTful APIs, PUT is often paired with resource URLs to indicate exactly which entity should be replaced. If the resource does not exist, some implementations may create it (sometimes referred to as “upsert”), though this behavior depends on the API specification.

PUT requests require the client to send the complete representation of the resource. Partial updates are usually handled by PATCH, which modifies only specified fields. This distinction ensures that PUT operations are predictable and consistent.

Security considerations include validating and sanitizing all incoming data, ensuring that only authorized users can modify the resource, and encrypting requests with TLS to protect data in transit. In modern web development, PUT is frequently used for updating user data, configurations, or documents via APIs in SaaS or cloud platforms like IaaS and PaaS.

In short, PUT enforces a precise server-side state, allowing developers to overwrite resources safely, predictably, and repeatedly without unintended duplication. It complements POST, GET, and DELETE to provide the essential toolkit of CRUD operations that power RESTful web services.

/poʊst/

n. “Send it, trust it, let it change the world.”

POST is an HTTP request method used to submit data to a server, typically causing a change in server state or triggering an action. Unlike GET, which only retrieves information, POST is intended for creating or updating resources. The client packages data in the request body, which the server interprets according to the endpoint’s rules.

For example, when submitting a form on https://catenco.de/contact, your browser sends a POST request containing fields like name, email, and message. The server then processes this data, perhaps storing it in a database, sending an email, or triggering another workflow.

POST requests are not idempotent, meaning repeating the same request can result in multiple side effects — like creating duplicate entries or sending multiple emails. This is why it is commonly paired with confirmation mechanisms, such as redirect-after-submit patterns, to prevent accidental repetition.

In web development, POST is central to RESTful APIs, form submissions, and any action where client input modifies server state. Tools like fetch in JavaScript, curl in the terminal, or libraries like Axios simplify creating POST requests with structured payloads such as JSON or URL-encoded forms.

Security considerations are critical when using POST. Since the data resides in the request body, it is not visible in URLs, unlike GET query strings. However, POST data still travels over the network and should always be encrypted using TLS to prevent interception. Input validation and server-side sanitization are necessary to avoid injection attacks or unintended consequences.

POST requests also support sending files, multipart form data, and complex objects, making them versatile for modern web applications. APIs often define POST endpoints for creating new resources, processing transactions, or interacting with services like SaaS platforms.

In summary, POST is the workhorse method for sending data, triggering actions, and enabling interactivity on the web. It complements GET and other HTTP methods, forming the foundation of request-response architecture that powers websites, apps, and APIs today.