Azure – Techy Chalkboard in bits and pieces

When working with Azure Storage Accounts configured in a private network, you may occasionally face connectivity issues, especially during programmatic operations like inserting entities into a Table Storage. Recently, while inserting a new entity, we encountered the following error:

ERROR: 
The request may be blocked by network rules of storage account. 
Please check network rule set using 
'az storage account show -n accountname --query networkRuleSet'.
If you want to change the default action to apply when no rule matches, 
please use 'az storage account update'.

This error clearly indicates that the network rules on the storage account are blocking the request. Here’s how we debugged and resolved the issue.

🧪 Problem Context

Our setup involves:

A private endpoint-enabled Azure Storage Account.
IP whitelisting done dynamically during the pipeline using GitHub Actions.
The following command used to allow the runner’s IP address:

az storage account network-rule add \
  --resource-group ${{ vars.RESOURCEGROUP_NAME }} \
  --account-name ${{ vars.STORAGEACCOUNT_NAME }} \
  --action Allow \
  --ip-address ${{ steps.ip.outputs.ipv4 }} \
  -o none --only-show-errors

Despite successfully executing this command, any immediate operation (like inserting into Table Storage) would fail with the aforementioned error.

🔍 Root Cause

Azure’s network rule updates—such as IP whitelisting—are not instantaneous. Even though the az command returns success, the rules can take 5 to 30 seconds to fully propagate across Azure’s networking stack.

This propagation delay means that your request may still be blocked right after whitelisting, resulting in transient errors.

✅ Resolution

To work around this, we added a short delay after the IP whitelist command before initiating any storage operations. Here’s a sample shell script update:

echo "Whitelisting IP: ${{ steps.ip.outputs.ipv4 }}"
az storage account network-rule add \
  --resource-group ${{ vars.RESOURCEGROUP_NAME }} \
  --account-name ${{ vars.STORAGEACCOUNT_NAME }} \
  --action Allow \
  --ip-address ${{ steps.ip.outputs.ipv4 }} \
  -o none --only-show-errors

echo "Waiting for network rule to propagate..."
sleep 30  # Adjust between 5-30 seconds based on testing

# Now perform the table insert operation

💡 Pro Tips

Use retries: If you’re automating this via scripts or CI/CD pipelines, consider implementing a retry mechanism instead of a fixed sleep.
Log current rules: Use the following command to verify if the IP is indeed whitelisted:
```
az storage account show -n <account-name> --query networkRuleSet.ipRules
```
Audit Logs: Check Azure Activity Logs for insights into rule application times.

🧾 Conclusion

When dealing with Azure Storage Accounts in a private network, remember that network rule changes aren’t immediate. Always plan for a short delay or retry logic to handle propagation time. This small adjustment can save hours of confusion and debugging.

Azure, Azure Integration Services

Unveiling the Secrets of Azure WAF & App Gateway Logs with KQL

April 1, 2025July 10, 2025 Manjunath

When running applications on Azure, ensuring security and performance is paramount. Azure Web Application Firewall (WAF) and Application Gateway generate extensive logs that help diagnose security threats, server failures, and performance bottlenecks. But how do you extract meaningful insights from these logs? The answer lies in Kusto Query Language (KQL).
In this blog post, I’ll guide you through some powerful KQL queries to analyze WAF logs and detect failures in Azure Application Gateway. Whether you’re a security analyst or a DevOps engineer, these queries will help you troubleshoot issues like a pro!

🔥 Detecting Blocked Requests by WAF
Azure WAF is designed to protect your applications from malicious requests. But how do you check if legitimate users are getting blocked?

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Block"
| project TimeGenerated, clientIp_s, requestUri_s, ruleName_s, details_data_s
| order by TimeGenerated desc

🛠️ How This Helps:
Identifies requests that were blocked by WAF.
Helps fine-tune WAF rules to reduce false positives.
Tracks client IPs and URLs being flagged as threats.
🚨 Identifying Application Gateway Failures
Application Gateway failures can be catastrophic for your users. If your app is throwing HTTP 500 errors, you need to know why.

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayAccessLog"
| where httpStatus_d >= 500
| project TimeGenerated, requestUri_s, httpStatus_d, backendPoolName_s,backendSettingName_s, host_s
| order by TimeGenerated desc

🛠️ Why This Query is Important:
Helps identify server-side failures.
Detects backend servers that may be down.
Quickly find affected URLs and services.
⚡ Uncovering High Latency Requests
Nobody likes a slow website. If users experience delays, they might leave your site frustrated. This query helps find slow API responses.

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayPerformanceLog"
| where timeTaken_d > 3000 // Requests taking more than 3 seconds
| project TimeGenerated, requestUri_s, timeTaken_d, clientIp_s, host_s
| order by timeTaken_d desc

🛠️ What You Gain:
Detects slow requests causing performance issues.
Identifies whether the delay is from the backend or frontend.
Helps optimize server response times.
🕵️ Tracking WAF Logs for a Specific Client IP
Want to investigate if a particular user or bot is getting blocked? This query is your best friend!

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where clientIp_s == "X.X.X.X" // Replace with actual client IP
| order by TimeGenerated desc

🛠️ Why Use This:
Track a specific user experiencing access issues.
Identify potential attackers trying to breach security.
Debug WAF rule misconfigurations.
💀 Detecting Backend Failures in App Gateway
Application Gateway connects to backend servers. If the backend is failing, requests will not be processed correctly.

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayAccessLog"
| where httpStatus_d <> "200"
| where requestUri_s = "/status-0123456789abcdef"
| project TimeGenerated, requestUri_s, httpStatus_d, backendPoolName_s, backendSettingName_s, host_s
| order by TimeGenerated desc

🛠️ Key Insights:
Detects backend servers going offline.
Helps analyze downtime patterns.
Prevents cascading failures in multi-server deployments.
Final Thoughts
Mastering KQL can transform the way you troubleshoot and secure your Azure infrastructure. Whether you’re dealing with WAF security issues, slow applications, or backend failures, these queries will make your life easier.
So, next time your boss asks, “Why is our app slow?” or “Why did a request get blocked?”, you know exactly where to look!
🔎 Have a favorite KQL query for Azure logs? Drop it in the comments below!

Azure, Azure Integration Services

Azure Logic Apps & Service Bus: When Do You Need the ‘Manage’ Claim?

March 5, 2025March 5, 2025 Manjunath

Ever wondered why your Azure Logic Apps sometimes fail to process messages consistently from a Service Bus queue? If you’ve run into issues with scaling, missing permissions, or unexpected failures, you’re not alone.

One of the key reasons for these inconsistencies is whether runtime scaling is enabled or disabled. And a major factor that affects this is the ‘Manage’ claim in your Service Bus connection string.

Understanding the Role of Runtime Scaling

Azure Functions that process messages from Service Bus queues can scale dynamically based on queue length. This is controlled by runtime scale monitoring. Whether you need the ‘Manage’ claim depends on whether this setting is enabled or not.

When Runtime Scaling is Enabled – ‘Manage’ Claim is Required

When runtime scaling is ON, Azure needs to check the active message count to decide whether to scale up.
To get this information, the system queries the Service Bus queue metadata.
Without the Manage claim in the connection string, the system cannot access queue details and fails to determine the active message count.

And that’s when you start seeing errors like this:

“Connection string does not have ‘Manage Claim’ for queue ‘[Queue_Name_Here]‘. Unable to determine active message count.”

Since it can’t retrieve the queue length, it falls back on alternative metrics:

“Failed to get queue description to derive queue length metrics. Falling back to using first message enqueued time.”

When Runtime Scaling is Disabled – ‘Manage’ Claim is NOT Required

When runtime scaling is OFF, Azure Functions do not need to query the queue length.
The function still processes messages as they arrive, but without automatic scaling.
Since it doesn’t check queue metadata, the Manage claim is not needed.

This is why, in some cases, disabling runtime scaling makes things appear to work more reliably. There’s no interference from scaling decisions, and messages just get processed at a steady rate.

How to Avoid Failures and Keep Things Running Smoothly

If You Want Scaling (Runtime Scaling ON)

✅ Make sure your Service Bus connection string has the Manage permission.
✅ Enable runtime scale monitoring in Azure Function settings.
✅ Keep an eye on scaling behavior in Application Insights to avoid thread pool starvation.

If You Don’t Need Scaling (Runtime Scaling OFF)

✅ No need for the ‘Manage’ claim—just Listen and Send permissions are enough.
✅ Adjust function concurrency settings to control the processing rate manually.
✅ Monitor your Service Bus queue to ensure messages don’t pile up.

By understanding how runtime scaling and permissions interact, you can avoid frustrating failures and keep your Azure Logic Apps running smoothly. Whether you need scaling or just steady processing, configuring things the right way makes all the difference.

Azure, Azure Integration Services, Nutshell Series

Understanding DNAT, Application, and Network Rules in Azure Firewall

February 16, 2025February 16, 2025 Manjunath

Azure Firewall is a cloud-native security service that provides advanced threat protection for Azure workloads. It supports three main rule types:

DNAT (Destination Network Address Translation) Rules – Used to expose internal resources externally.
Application Rules – Controls outbound HTTP(S) traffic using FQDNs, URL filtering, and web categories.
Network Rules – Filters non-HTTP(S) traffic based on IP addresses, ports, and service tags.

1. DNAT (Destination Network Address Translation) Rules

DNAT rules allow inbound traffic from the internet. This traffic can be redirected to a private resource inside an Azure Virtual Network (VNet).

Example DNAT Rule

Source Type/IP/IP Group	Destination IP/Port	Translated IP/FQDN	Translated Port	Protocol
52.10.20.30	443	10.1.0.10 or app.internal.local	443	TCP or UDP

2. Application Rules

Application rules control outbound HTTP(S) traffic using:

FQDNs (e.g., *.microsoft.com)
FQDN Tags (e.g., WindowsUpdate, AzureActiveDirectory)
URL Filtering (block specific URLs)
Web Categories (e.g., Social Networking, Streaming)

Example Application Rule

Source IP Range	Protocol	Port	Allowed FQDNs	FQDN Tag	Web Category
10.0.0.0/24	HTTPS	443	*.microsoft.com	WindowsUpdate	Shopping

3. Network Rules

Network rules filter non-HTTP(S) traffic using:

IP Addresses
Service Tags (e.g., AzureSQL, Storage)
IP Groups
FQDNs

Example Network Rule

Source IP Range	Destination IP/FQDN	Protocol	Port	Service Tag
10.1.0.0/24	10.2.0.10 or db.internal.local	TCP	1433 (SQL)	AzureSQL

4. Comparison of DNAT, Application, and Network Rules

Destination Types

Rule Type	Best For	Filters By	Supports FQDN?	Supports FQDN Tags?	Supports URL Filtering?	Supports Web Categories?	Supports Service Tags?	Supports IP Groups?	Supports IP Addresses?
DNAT Rules	Inbound traffic redirection	Firewall IP → Translated IP/FQDN	✅	❌	❌	❌	❌	❌	✅ (Destination)
Application Rules	Outbound HTTP(S) control	FQDNs, FQDN Tags, URLs, Web Categories	✅	✅	✅	✅	❌	❌	❌
Network Rules	Non-HTTP traffic control	IP, Service Tags, FQDN, IP Groups	✅	❌	❌	❌	✅	✅	✅

5. When to Use Each Rule Type

DNAT Rules – Expose internal resources to external users.
Application Rules – Control outbound HTTP(S) traffic with FQDN, URL filtering, and Web Categories.
Network Rules – Allow or block non-HTTP(S) traffic based on IPs, Service Tags, and IP Groups.

Azure, Azure Integration Services, Nutshell Series

Azure Tagging Strategies

September 25, 2024September 25, 2024 Manjunath

Tags in Azure help organize resources for cost management, governance, and automation. Here’s a quick guide to effective tagging.

Common Tag Categories

Owner: Who is responsible for the resource (e.g., Owner).
Billing: Track costs (e.g., CostCenter, Project).
Environment: Classify resources by environment (e.g., Production, Development).
Application: Identify apps or services (e.g., Application, Role).
Compliance: Ensure security and compliance (e.g., Compliance, DataClassification).

Best Practices

Use consistent tag keys and values.
Inherit tags to all resources from resource groups.
Limit tags to essentials for simplicity.
Automate tagging using Azure Policy and CLI.
Leverage tags for cost tracking and governance.

“Tags are vital for managing cloud resources efficiently in Azure.”
– Azure Expert

Learn More About Azure Tags

Azure, Azure Integration Services, Nutshell Series, Technology and tricks

Essential Network Commands – Nutshell

September 18, 2024August 6, 2025 Manjunath

Managing network connections and diagnosing issues can be made easier by using the right network commands. Here’s a quick guide to essential network commands for Windows, Azure Function Apps Console, and OpenSSL.

1. Windows Network Commands

Command	Environment	Description	Example
`ipconfig`	Windows (CMD)	Displays network configuration	`ipconfig`
`Get-NetIPAddress`	Windows (PowerShell)	PowerShell version of ipconfig	`Get-NetIPAddress`
`ping`	Windows (CMD)	Tests connectivity to a host	`ping google.com`
`Test-Connection`	Windows (PowerShell)	PowerShell version of ping	`Test-Connection google.com`
`tracert`	Windows (CMD)	Traces network packet route	`tracert google.com`
`Test-NetConnection`	Windows (PowerShell)	PowerShell version of tracert	`Test-NetConnection google.com -TraceRoute`
`netstat`	Windows (CMD)	Shows active connections	`netstat -an`
`Get-NetTCPConnection`	Windows (PowerShell)	PowerShell version of netstat	`Get-NetTCPConnection`

2. Azure Function Apps Console Network Commands

Command	Environment	Description	Example
`curl`	Azure Function Apps	Tests network/API endpoint	`curl https://example.com`
`nslookup`	Azure Function Apps	Resolves DNS name	`nslookup example.com`
`ping`	Azure Function Apps	Tests connectivity to a remote host	`ping example.com`
`traceroute`	Azure Function Apps	Traces packet path to a host	`traceroute example.com`

3. OpenSSL Command

Command Environment Description Example

Command	Environment	Description	Example
`openssl s_client -connect`	OpenSSL (CMD, Console)	Tests SSL/TLS connection to a host Pass additional parameter -tls1 or -tls1_1 or -tls1_2 or -tls1_3 or -ssl3 to check appropriate TLS/SSL protocols	`openssl s_client -connect example.com:443`

openssl s_client -connect

OpenSSL (CMD, Console)

Tests SSL/TLS connection to a host

Pass additional parameter -tls1 or -tls1_1 or -tls1_2 or -tls1_3 or -ssl3 to check appropriate TLS/SSL protocols

openssl s_client -connect example.com:443

These commands can simplify network troubleshooting across various environments: Windows, Azure Function Apps, and OpenSSL. With the right tools, managing your network connections becomes more efficient and secure.

Azure, Nutshell Series, Uncategorized

ABC of cloud computing! – Nutshell

September 16, 2024September 16, 2024 Manjunath

Cloud computing has transformed the way businesses manage and deliver technology services. Let’s break it down in simple terms, starting with the ABC of cloud computing:

A – Availability

Definition: Availability refers to the uptime and accessibility of cloud services. High availability ensures that your cloud resources are always accessible when you need them.

Importance: Ensures that mission-critical applications remain functional with minimal downtime.
Key Features: Redundancy, fault tolerance, and service-level agreements (SLAs).

B – Backup

Definition: Backup is the process of copying and storing your data in the cloud to protect against data loss or corruption.

Importance: Critical for disaster recovery and business continuity.
Key Features: Automated backups, data encryption, and versioning.

C – Cost Efficiency

Definition: Cloud computing offers flexible pricing models that allow businesses to pay only for the resources they use, leading to potential cost savings compared to traditional IT infrastructure.

Importance: Helps businesses optimize expenses and avoid large capital investments in hardware.
Key Features: Pay-as-you-go models, resource scaling, and pricing transparency.

D – Data Security

Definition: Cloud providers offer robust security measures to protect data from unauthorized access, breaches, and attacks.

Importance: Safeguarding sensitive data is essential for maintaining trust and compliance with regulations.
Key Features: Encryption, multi-factor authentication, and firewalls.

E – Elasticity

Definition: Elasticity in cloud computing refers to the ability to automatically scale resources up or down based on demand.

Importance: Ensures optimal resource utilization and cost efficiency.
Key Features: Auto-scaling, dynamic provisioning, and load balancing.

F – Flexibility

Definition: Cloud platforms provide flexibility by offering a wide range of services, platforms, and tools to meet various business needs.

Importance: Allows businesses to tailor their cloud environment to specific use cases.
Key Features: Multi-cloud strategies, platform compatibility, and APIs.

Conclusion

The ABC of cloud computing – Availability, Backup, Cost Efficiency – and beyond, such as Data Security, Elasticity, and Flexibility, provides a foundational understanding of how cloud services can transform modern businesses. By leveraging these key aspects, organizations can optimize their operations and scale effectively.

Azure, Azure Integration Services, Nutshell Series, Technology and tricks

Basic Azure CLI Commands – Nutshell

September 16, 2024September 16, 2024 Manjunath

Authentication & Subscription


# Login to Azure:
az login

# Show current subscription:
az account show

# List all subscriptions:
az account list

# Set active subscription:
az account set --subscription <subscription-id>

Resource Groups


# Create a resource group:
az group create --name <resource-group-name> --location <location>

# List all resource groups:
az group list

# Delete a resource group:
az group delete --name <resource-group-name> --yes

Virtual Machines (VMs)


# List all VMs:
az vm list --output table

# Create a VM:
az vm create --resource-group <resource-group-name> --name <vm-name> --image <image> --admin-username <username> --admin-password <password>

# Start a VM:
az vm start --name <vm-name> --resource-group <resource-group-name>

# Stop a VM:
az vm stop --name <vm-name> --resource-group <resource-group-name>

# Delete a VM:
az vm delete --resource-group <resource-group-name> --name <vm-name>

Storage Accounts


# Create a storage account:
az storage account create --name <storage-account-name> --resource-group <resource-group-name> --location <location> --sku Standard_LRS

# List storage accounts:
az storage account list --output table

# Delete a storage account:
az storage account delete --name <storage-account-name> --resource-group <resource-group-name>

Blob Storage


# Create a container in a storage account:
az storage container create --name <container-name> --account-name <storage-account-name>

# Upload a file to a container:
az storage blob upload --container-name <container-name> --file <file-path> --name <blob-name> --account-name <storage-account-name>

# List blobs in a container:
az storage blob list --container-name <container-name> --account-name <storage-account-name> --output table

# Download a blob:
az storage blob download --container-name <container-name> --name <blob-name> --file <destination-path> --account-name <storage-account-name>

App Services


# Create an App Service plan:
az appservice plan create --name <plan-name> --resource-group <resource-group-name> --sku B1 --is-linux

# Create a web app:
az webapp create --resource-group <resource-group-name> --plan <plan-name> --name <webapp-name> --runtime "NODE|14-lts"

# List web apps:
az webapp list --output table

# Delete a web app:
az webapp delete --resource-group <resource-group-name> --name <webapp-name>

Azure Function Apps


# Create a function app:
az functionapp create --resource-group <resource-group-name> --consumption-plan-location <location> --name <functionapp-name> --storage-account <storage-account-name> --runtime <runtime>

# List function apps:
az functionapp list --output table

# Delete a function app:
az functionapp delete --resource-group <resource-group-name> --name <functionapp-name>

Service Bus


# Create a Service Bus namespace:
az servicebus namespace create --resource-group <resource-group-name> --name <namespace-name> --location <location>

# Create a Service Bus queue:
az servicebus queue create --resource-group <resource-group-name> --namespace-name <namespace-name> --name <queue-name>

# List Service Bus namespaces:
az servicebus namespace list --output table

# Delete a Service Bus namespace:
az servicebus namespace delete --resource-group <resource-group-name> --name <namespace-name>

Key Vault


# Create a Key Vault:
az keyvault create --name <keyvault-name> --resource-group <resource-group-name> --location <location>

# List Key Vaults:
az keyvault list --output table

# Delete a Key Vault:
az keyvault delete --name <keyvault-name> --resource-group <resource-group-name>

Azure Monitor


# List metrics for a resource:
az monitor metrics list --resource <resource-id>

# List activity logs:
az monitor activity-log list --output table

Logic Apps


# Create a Logic App:
az logic workflow create --resource-group <resource-group-name> --name <logic-app-name> --location <location>

# List Logic Apps:
az logic workflow list --resource-group <resource-group-name> --output table

# Delete a Logic App:
az logic workflow delete --resource-group <resource-group-name> --name <logic-app-name>

Event Grid


# Create an Event Grid topic:
az eventgrid topic create --name <topic-name> --resource-group <resource-group-name> --location <location>

# List Event Grid topics:
az eventgrid topic list --resource-group <resource-group-name> --output table

# Delete an Event Grid topic:
az eventgrid topic delete --name <topic-name> --resource-group <resource-group-name>

Event Hubs


# Create an Event Hubs namespace:
az eventhubs namespace create --name <namespace-name> --resource-group <resource-group-name> --location <location>

# Create an Event Hub:
az eventhubs eventhub create --resource-group <resource-group-name> --namespace-name <namespace-name> --name <eventhub-name>

# List Event Hubs in a namespace:
az eventhubs eventhub list --resource-group <resource-group-name> --namespace-name <namespace-name> --output table

# Delete an Event Hub:
az eventhubs eventhub delete --resource-group <resource-group-name> --namespace-name <namespace-name> --name <eventhub-name>

.Net, Azure, C#, Cloud Design Patterns, Nutshell Series, Technology and tricks

SOLID Principles (with c# examples) – Nutshell

September 15, 2024October 10, 2025 Manjunath

SOLID Principles in .NET – Explained with Examples

The SOLID principles are five guidelines that help developers write clean, maintainable, and extensible object-oriented code.
Below we go through each principle with concise C# examples showing what is bad and what is good.

1. Single Responsibility Principle (SRP)

Rule: A class should have only one reason to change.

Bad Example

public class User
{
    public string Name { get; set; }
    public string Email { get; set; }

    public void SendEmail(string message)
    {
        // Logic to send email
    }
}

Here, User manages both data and email-sending logic. It has more than one responsibility.

Good Example

public class User
{
    public string Name { get; set; }
    public string Email { get; set; }
}

public class EmailService
{
    public void SendEmail(string email, string message)
    {
        // Logic to send email
    }
}

User now manages only user data, while EmailService handles emails. Each has one responsibility.

2. Open/Closed Principle (OCP)

Rule: Classes should be open for extension but closed for modification.

Bad Example

public class AreaCalculator
{
    public double CalculateArea(object shape)
    {
        if (shape is Circle c)
            return Math.PI * c.Radius * c.Radius;
        if (shape is Square s)
            return s.Side * s.Side;
        return 0;
    }
}

Adding a new shape forces us to modify AreaCalculator, violating OCP.

Good Example

public abstract class Shape
{
    public abstract double Area();
}

public class Circle : Shape
{
    public double Radius { get; set; }
    public override double Area() => Math.PI * Radius * Radius;
}

public class Square : Shape
{
    public double Side { get; set; }
    public override double Area() => Side * Side;
}

Each shape implements its own Area. Adding new shapes doesn’t require changing existing code.

3. Liskov Substitution Principle (LSP)

Rule: Derived classes should be substitutable for their base types without breaking behavior.

Bad Example

public class Bird
{
    public virtual void Fly() { }
}

public class Ostrich : Bird
{
    public override void Fly()
    {
        throw new NotImplementedException();
    }
}

Substituting Ostrich for Bird breaks behavior, since ostriches cannot fly.

Good Example

public abstract class Shape
{
    public abstract double Area();
}

public class Rectangle : Shape
{
    public double Width { get; set; }
    public double Height { get; set; }
    public override double Area() => Width * Height;
}

Rectangle correctly substitutes Shape and can be used anywhere Shape is expected.

4. Interface Segregation Principle (ISP)

Rule: Don’t force classes to implement methods they don’t use.

Bad Example

public interface IMachine
{
    void Print();
    void Scan();
}

public class SimplePrinter : IMachine
{
    public void Print() { }
    public void Scan() { throw new NotImplementedException(); }
}

SimplePrinter doesn’t support scanning, yet it is forced to implement it.

Good Example

public interface IPrinter
{
    void Print();
}

public interface IScanner
{
    void Scan();
}

public class MultiFunctionPrinter : IPrinter, IScanner
{
    public void Print()
    {
        Console.WriteLine("Printing document...");
    }

    public void Scan()
    {
        Console.WriteLine("Scanning document...");
    }
}

Now classes only implement what they need. A simple printer just implements IPrinter.

5. Dependency Inversion Principle (DIP)

Rule: High-level modules should not depend on low-level modules. Both should depend on abstractions.

Bad Example

public class DataManager
{
    private readonly SQLDatabase _db = new SQLDatabase();

    public void Save(string data)
    {
        _db.SaveData(data);
    }
}

public class SQLDatabase
{
    public void SaveData(string data) { }
}

DataManager is tightly coupled to SQLDatabase, making it hard to switch databases.

Good Example

public interface IDatabase
{
    void SaveData(string data);
}

public class SQLDatabase : IDatabase
{
    public void SaveData(string data)
    {
        // Save data to SQL database
    }
}

public class DataManager
{
    private readonly IDatabase _database;
    public DataManager(IDatabase database)
    {
        _database = database;
    }

    public void Save(string data)
    {
        _database.SaveData(data);
    }
}

DataManager now depends on IDatabase. Any database implementation can be injected.

Key Takeaways

SRP — One class, one responsibility.
OCP — Extend, don’t modify working code.
LSP — Subtypes must preserve base-class behavior.
ISP — Keep interfaces small and focused.
DIP — Depend on abstractions, not concretions.

Azure, Azure Integration Services, Design Patterns, Technology and tricks

Restful API design principles – Nutshell

September 8, 2024September 14, 2024 Manjunath

HTTP Verb	Query	Description
GET	/users	Retrieves a list of users
GET	/users/8	Retrieves a specific user
POST	/users	Creates a new user
PUT	/users/8	Updates user #8
PATCH	/users/8	Partially updates
PATCH	/users/8/status	Updates status against user #8
DELETE	/users/8	Deletes user #8

RESTful APIs are vital for modern web applications, providing a flexible and scalable way for systems to communicate. Here’s a quick guide to key principles, best practices, HTTP methods, status codes, and common errors.

Key RESTful Principles

1. Uniform Interface: Resources identified by URLs (e.g., “/users/123”) using HTTP methods (“GET”, “POST”, etc.).
2. Stateless: Each request includes all information required; no session state stored server-side.
3. Client-Server Separation: Clients handle UI, while servers manage data and logic independently.
4. Cacheable: Define caching rules (e.g., “Cache-Control”) to improve performance.
5. Layered System: Clients interact with layers (e.g., proxies) without knowing internal server details.

Best Practices

1. Use Nouns in URLs: “/users”, not “/getUsers”.
2. Version Your API: “/v1/users”, to maintain backward compatibility.
3. Use Proper Status Codes: Ensure clear communication of the outcome.
4. Paginate Large Responses: For example, “GET /users?page=1&limit=50”.
5. Secure Your API: Use authentication (OAuth, API keys) and HTTPS.

HTTP Methods and REST Mapping

– GET: Retrieve data (read).
– Example: “GET /users/123” – Get user with ID 123.
– POST: Create a new resource.
– Example: “POST /users” – Create a new user.
– PUT: Update or replace an existing resource.
– Example: “PUT /users/123” – Update user with ID 123.
– PATCH: Partially update a resource.
– Example: “PATCH /users/123” – Update a user’s email.
– DELETE: Remove a resource.
– Example: “DELETE /users/123” – Delete user with ID 123.

HTTP Status Codes

– Success:
– “200 OK”: Request succeeded (GET, PUT).
– “201 Created”: New resource created (POST).
– “204 No Content”: Request successful, no content to return (DELETE).

– Client-Side Errors:
– “400 Bad Request”: Malformed request.
– “401 Unauthorized”: Authentication required.
– “403 Forbidden”: Access denied.
– “404 Not Found”: Resource not found.

– Server-Side Errors:
– “500 Internal Server Error”: Generic server failure.
– “502 Bad Gateway”: Invalid response from an upstream server.
– “503 Service Unavailable”: Server temporarily unable to handle the request.

By following these principles and best practices, you can design scalable, secure, and maintainable RESTful APIs that provide a seamless experience for users and developers alike.