The Fully Qualified Domain Name (FQDN) is the complete and unique name of a computer or host on the internet or a local network. It consists of multiple parts that reflect a hierarchical structure.

Structure of an FQDN

An FQDN is made up of three main components:

1. Hostname – The specific name of a computer or service (e.g., www).

2. Domain Name – The name of the higher-level domain (e.g., example).

3. Top-Level Domain (TLD) – The highest level of the domain structure (e.g., .com).

Example of an FQDN:
👉 www.example.com.

• www → Hostname

• example → Domain name

• .com → Top-Level Domain

• The trailing dot (.) is optional and represents the root domain of the DNS system.

Why is the FQDN important?

✅ Uniqueness: Each FQDN is globally unique and refers to a specific resource on the internet.
✅ DNS Resolution: It is used by DNS servers to find the IP address of websites and servers.
✅ SSL Certificates: An FQDN is often required for SSL/TLS certificates to ensure secure connections.
✅ Email Delivery: Mail servers use FQDNs to send emails to the correct hosts.

Difference Between an FQDN and a Simple Domain

• FQDN: mail.google.com (fully specified)

• Simple Domain: google.com (can contain multiple hosts, e.g., www, mail, ftp)

In summary, the FQDN is the complete address of a device or service on the internet, while a simple domain is a more general address.

A Bearer Token is a type of access token used for authentication and authorization in web applications and APIs. The term "Bearer" means "holder," which implies that anyone in possession of the token can access protected resources—without additional verification.

Characteristics of a Bearer Token:

• Self-contained: It includes all necessary authentication information.
• No additional identity check: Whoever holds the token can use it.
• Sent in HTTP headers: Typically as Authorization: Bearer <token>.
• Often time-limited: Tokens have expiration times to reduce misuse.
• Commonly used with OAuth 2.0: For example, when authenticating with third-party services.

Example of an HTTP request with a Bearer Token:

GET /protected-data HTTP/1.1
Host: api.example.com
Authorization: Bearer abcdef123456

Risks:

• No protection if stolen: If someone intercepts the token, they can impersonate the user.
• Must be securely stored: Should not be exposed in client-side code or URLs.

💡 Tip: To enhance security, use short-lived tokens and transmit them only over HTTPS.

OAuth (Open Authorization) is an open standard protocol for authorization that allows applications to access a user's resources without knowing their credentials (e.g., password). It is commonly used for Single Sign-On (SSO) and API access.

How Does OAuth Work?

OAuth operates using tokens, which allow an application to access a user's data on their behalf. The typical flow is as follows:

1. Authorization Request: An application (client) requests access to a user’s protected data (e.g., Facebook contacts).
2. User Authentication: The user is redirected to the provider's login page (e.g., Google, Facebook) and enters their credentials.
3. Permission Granting: The user confirms that the application can access specific data.
4. Token Issuance: The application receives an access token, which grants permission to access the approved data.
5. Resource Access: The application uses the token to make requests to the API server without needing the user's password.

OAuth 1.0 vs. OAuth 2.0

• OAuth 1.0: More complex, uses cryptographic signatures but is secure.
• OAuth 2.0: Simpler, relies on HTTPS for security, and is the most commonly used version today.

Real-World Uses of OAuth

• "Sign in with Google/Facebook/Apple" buttons
• Third-party apps accessing Google Drive, Dropbox, or Twitter APIs
• Payment services like PayPal integrating with other apps

Entity headers are HTTP headers that provide information about the body of a message. They can appear in both requests and responses, describing properties of the content such as type, length, encoding, or last modification date.

Important Entity Headers:

1. Content-Type

• Specifies the media type (MIME type) of the content.
• Example:

Content-Type: application/json; charset=UTF-8

2. Content-Length

• Indicates the size of the content in bytes.
• Example:

Content-Length: 1024

3. Content-Encoding

• Shows if the content has been compressed (e.g., gzip).
• Example:

Content-Encoding: gzip

4. Content-Language

• Specifies the language of the content.
• Example:

Content-Language: de-DE

5. Cache-Location

• Indicates the URL or storage location of the actual resource.
• Example:

Content-Location: /files/document.pdf

6. Last-Modified

• Specifies when the content was last changed.
• Example:

Last-Modified: Tue, 30 Jan 2025 14:20:00 GMT

7. ETag

• A unique identifier for a version of the resource, useful for caching.
• Example:

ETag: "abc123xyz"

8. Expires

• Indicates when the content should be considered outdated.
• Example:

Expires: Fri, 02 Feb 2025 12:00:00 GMT

9. Allow

• Lists the allowed HTTP methods for a resource.
• Example:

Allow: GET, POST, HEAD

10. Refresh  (Not standardized but often used)

• Instructs the browser to refresh the page after a specified time.
• Example:

Refresh: 10; url=https://example.com

These headers help describe the content of an HTTP message, optimize caching strategies, and ensure correct rendering.

Request headers are HTTP headers sent by a client (e.g., a web browser or API request) to the server, providing additional information about the request, the client, or the desired content.

Important Request Headers:

1. Host

• Specifies the target domain or IP address of the server.
• Example:

Host: www.example.com

2. User-Agent

• Contains information about the client, such as browser type or operating system.
• Example:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

3. Accept

• Defines which content types the client can accept.
• Example:

Accept: text/html, application/json

4. Accept-Language

• Specifies the client's preferred language(s).
• Example:

Accept-Language: de-DE, en-US

5. Accept-Encoding

• Indicates which compression formats the client supports.
• Example:

Accept-Encoding: gzip, deflate, br

6. Referer

• Provides the previous page from which the user navigated.
• Example:

Referer: https://www.google.com/

7. Authorization

• Used for authentication when accessing protected resources.
• Example(Basic Auth):

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

8. Cookie

• Contains cookies previously set by the server.
• Example:

Cookie: sessionId=abc123; theme=dark

9. Content-Type (for POST/PUT-Anfragen)

• Specifies the data format of the request body.
• Example:

Content-Type: application/json

10. Origin

• Indicates the origin URL and is often used in Cross-Origin requests.
• Example:

Origin: https://www.example.com

These headers help the server understand the request and respond accordingly by providing details about the client, preferred content, and security aspects.

General HTTP headers are headers that can be used in both HTTP requests and responses. They contain general information about the connection and data transfer that is not specific to the client, server, or content.

Wichtige allgemeine Header:

1. Cache-Control

• Controls caching behavior for clients or proxy servers.
• Example:

Cache-Control: no-cache, no-store, must-revalidate

2. Connection

• Defines whether the connection should remain open after the request.
• Example:

Connection: keep-alive

3. Date

• Contains the date and time of the HTTP message in GMT format.
• Example:

Date: Wed, 31 Jan 2025 12:34:56 GMT

4. Pragma (veraltet, aber noch genutzt)

• Similar to Cache-Control, mainly used for backward-compatible caching rules.für rückwärtskompatible Caching-Regeln genutzt.
• Example:

Pragma: no-cache

5. Trailer

• Specifies which headers will be sent after the message body.
• Example:

Trailer: Expires

6. Transfer-Encoding

• Specifies how the message body is transferred, e.g., in chunks.
• Example:

Transfer-Encoding: chunked

7. Upgrade

• Used to upgrade the connection to a different protocol, such as WebSockets.
• Example:

Upgrade: websocket

8. Via

• Indicates through which proxies or gateways the message was routed.
• Example:

Via: 1.1 proxy.example.com

These headers improve communication between the client and server, manage caching, and allow protocol upgrades.

HTTP headers are metadata exchanged between the client (e.g., a browser) and the server during HTTP requests and responses. They contain important information for communication, such as:

1. General headers – Apply to both requests and responses (e.g., Cache-Control for caching rules).
2. Request headers – Provide details about the client's request (e.g., User-Agent, which identifies the browser type).
3. Response headers – Contain information about the server's response (e.g., Server, which indicates the web server used).
4. Entity headers – Describe the content of the message (e.g., Content-Type, which specifies the media type of the response).

Example of an HTTP request with headers:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

Example of an HTTP response with headers:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 3456
Server: Apache

HTTP headers are commonly used for security (e.g., Strict-Transport-Security), performance optimization (e.g., Cache-Control), and authentication (e.g., Authorization).

A Remote Function Call (RFC) is a method that allows a computer program to execute a function on a remote system as if it were called locally. RFC is commonly used in distributed systems to facilitate communication and data exchange between different systems.

Key Principles:

1. Transparency: Calling a remote function is done in the same way as calling a local function, abstracting the complexities of network communication.
2. Client-Server Model: The calling system (client) sends a request to the remote system (server), which executes the function and returns the result.
3. Protocols: RFC relies on standardized protocols to ensure data is transmitted accurately and securely.

Examples:

• SAP RFC: In SAP systems, RFC is used to exchange data between different modules or external systems. Types include synchronous RFC (sRFC), asynchronous RFC (aRFC), transactional RFC (tRFC), and queued RFC (qRFC).
• RPC (Remote Procedure Call): RFC is a specific implementation of the broader RPC concept, used in technologies like Java RMI or XML-RPC.

Applications:

• Integrating software modules across networks.
• Real-time communication between distributed systems.
• Automation and process control in complex system landscapes.

Benefits:

• Efficiency: No direct access to the remote system is required.
• Flexibility: Systems can be developed independently.
• Transparency: Developers don’t need to understand underlying network technology.

Challenges:

• Network Dependency: Requires a stable connection to function.
• Error Management: Issues like network failures or latency can occur.
• Security Risks: Data transmitted over the network must be protected.

Contract Driven Development (CDD) is a software development approach that focuses on defining and using contracts between different components or services. These contracts clearly specify how various software parts should interact with each other. CDD is commonly used in microservices architectures or API development to ensure that communication between independent modules is accurate and consistent.

Key Concepts of CDD

1. Contracts as a Single Source of Truth:

   • A contract is a formal specification (e.g., in JSON or YAML) of a service or API that describes which endpoints, parameters, data formats, and communication expectations exist.
   • The contract is treated as the central resource upon which both client and server components are built.

2. Separation of Implementation and Contract:

   • The implementation of a service or component must comply with the defined contract.
   • Clients (users of this service) build their requests based on the contract, independent of the actual server-side implementation.

3. Contract-Driven Testing:

   • A core aspect of CDD is using automated contract tests to verify compliance with the contract. These tests ensure that the interaction between different components adheres to the specified expectations.
   • For example, a Consumer-Driven Contract test can be used to ensure that the data and formats expected by the consumer are provided by the provider.

Benefits of Contract Driven Development

1. Clear Interface Definition: Explicit specification of contracts clarifies how components interact, reducing misunderstandings and errors.
2. Independent Development: Teams developing different services or components can work in parallel as long as they adhere to the defined contract.
3. Simplified Integration and Testing: Since contracts serve as the foundation, mock servers or clients can be created based on these specifications, enabling integration testing without requiring all components to be available.
4. Increased Consistency and Reliability: Automated contract tests ensure that changes in one service do not negatively impact other systems.

Use Cases for CDD

• Microservices Architectures: In complex distributed systems, CDD helps define and stabilize communication between services.
• API Development: In API development, a contract ensures that the exposed interface meets the expectations of users (e.g., other teams or external customers).
• Consumer-Driven Contracts: For consumer-driven contracts (e.g., using tools like Pact), consumers of a service define the expected interactions, and providers ensure that their services fulfill these expectations.

Disadvantages and Challenges of CDD

1. Management Overhead:

   • Maintaining and updating contracts can be challenging, especially with many services involved or in a dynamic environment.

2. Versioning and Backward Compatibility:

   • If contracts change, both providers and consumers need to be synchronized, which can require complex coordination.

3. Over-Documentation:

   • In some cases, CDD can lead to an excessive focus on documentation, reducing flexibility.

Conclusion

Contract Driven Development is especially suitable for projects with many independent components where clear and stable interfaces are essential. It helps prevent misunderstandings and ensures that the communication between services remains robust through automated testing. However, the added complexity of managing contracts needs to be considered.

RESTful (Representational State Transfer) describes an architectural style for distributed systems, particularly for web services. It is a method for communication between client and server over the HTTP protocol. RESTful web services are APIs that follow the principles of the REST architectural style.

Core Principles of REST:

1. Resource-Based Model:

   • Resources are identified by unique URLs (URIs). A resource can be anything stored on a server, like database entries, files, etc.

2. Use of HTTP Methods:

   • RESTful APIs use HTTP methods to perform various operations on resources:
     • GET: To retrieve a resource.
     • POST: To create a new resource.
     • PUT: To update an existing resource.
     • DELETE: To delete a resource.
     • PATCH: To partially update an existing resource.

3. Statelessness:

   • Each API call contains all the information the server needs to process the request. No session state is stored on the server between requests.

4. Client-Server Architecture:

   • Clear separation between client and server, allowing them to be developed and scaled independently.

5. Cacheability:

   • Responses should be marked as cacheable if appropriate to improve efficiency and reduce unnecessary requests.

6. Uniform Interface:

   • A uniform interface simplifies and decouples the architecture, relying on standardized methods and conventions.

7. Layered System:

   • A REST architecture can be composed of hierarchical layers (e.g., servers, middleware) that isolate components and increase scalability.

Example of a RESTful API:

Assume we have an API for managing "users" and "posts" in a blogging application:

URLs and Resources:

• /users: Collection of all users.
• /users/{id}: Single user with ID {id}.
• /posts: Collection of all blog posts.
• /posts/{id}: Single blog post with ID {id}.

HTTP Methods and Operations:

• GET /users: Retrieves a list of all users.
• GET /users/1: Retrieves information about the user with ID 1.
• POST /users: Creates a new user.
• PUT /users/1: Updates information for the user with ID 1.
• DELETE /users/1: Deletes the user with ID 1.

Example API Requests:

• GET Request:

GET /users/1 HTTP/1.1
Host: api.example.com

Response:

{
  "id": 1,
  "name": "John Doe",
  "email": "john.doe@example.com"
}

POST Request:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Smith",
  "email": "jane.smith@example.com"
}

Response:

HTTP/1.1 201 Created
Location: /users/2

Advantages of RESTful APIs:

• Simplicity: By using HTTP and standardized methods, RESTful APIs are easy to understand and implement.
• Scalability: Due to statelessness and layered architecture, RESTful systems can be easily scaled.
• Flexibility: The separation of client and server allows for independent development and deployment.

RESTful APIs are a widely used method for building web services, offering a simple, scalable, and flexible architecture for client-server communication.