3.1 Web API Basics

1. Introduction

A Web API (Application Programming Interface) is an interface that allows communication between different software applications over the web, typically using the HTTP/HTTPS protocol. It provides a way for applications to interact with each other, enabling data exchange and functionality to be used remotely.

1.1 Key Aspects of a Web API:

1. HTTP-based Communication:

   • Web APIs usually expose resources via HTTP methods like:
     • GET (to retrieve data)
     • POST (to send data)
     • PUT (to update data)
     • DELETE (to delete data)

2. Data Format:

   • The most common format for data exchange in Web APIs is JSON (JavaScript Object Notation) or XML.

3. Stateless:

   • Web APIs are typically stateless, meaning each request from the client to the server must contain all the information the server needs to fulfill the request, and no client state is stored on the server between requests.

4. Client-Server Architecture:

   • The Web API operates on a client-server model where the client sends requests to the API, and the server processes the request and returns a response.

1.2 Example:

• A Web API might expose an endpoint like https://api.weather.com/current?city=London to provide current weather information for a specified city.
• The client (such as a mobile app or website) would make a request to that URL, and the server would return the weather data in JSON format, like:

  {
    "temperature": "22°C",
    "condition": "Sunny"
  }

1.3 Common Use Cases

• Web services: Allow interaction between different applications (e.g., mobile apps consuming data from a cloud service).
• Microservices: Each service in a microservice architecture might expose a Web API for other services to interact with it.
• Integrations: Allow external developers or services to integrate with a platform (e.g., third-party developers accessing a payment API).

1.4 Web API in ASP.NET

• ASP.NET provides a framework for building RESTful Web APIs using the ASP.NET Core or ASP.NET MVC frameworks. These APIs can be consumed by any client (e.g., web browsers, mobile apps) that can send HTTP requests.

1. REST / RESTful API

REST stands for REpresentationalState Transfer. REST (Representational State Transfer) is an architectural style for building web services. It relies on stateless communication and typically uses HTTP methods (GET, POST, PUT, DELETE) to perform CRUD (Create, Read, Update, Delete) operations on resources. REST APIs return data in a format like JSON or XML.

• In traditional Web architecture, clients (our browsers) connect to Web servers for web pages.

• In REST architecture, clients (browsers, mobile apps) connect to Web servers for Resources.

• Resource: a resource can be any object the server can provide information about. For example, a resource can be a user, a photo, a comment. Each resource has a unique identifier.

• Example: http://www.curtin.edu.au/cse/students

Tip

When a RESTful API is called, the server will transfer to the client the representation of the state of the requested resource.

Lear more on REST

2. ASP.NET to build RESTful services

In ASP.NET, Web API is a framework used to build RESTful services. It allows developers to create HTTP services that can be consumed by browsers, mobile devices, and other platforms.

1. HTTP Methods: ASP.NET Web API uses HTTP methods (GET, POST, PUT, DELETE) to implement RESTful services.

   • GET retrieves data.
   • POST creates data.
   • PUT updates data.
   • DELETE removes data.

2. Routing: ASP.NET Web API maps HTTP requests to actions in a controller based on routing rules.

   • Example: /api/books could map to a BooksController where the GetBooks() method is called for GET requests.

3. Stateless: Each request from a client to a server must contain all the information needed to understand the request, adhering to REST’s stateless nature.

4. Resource-Oriented: ASP.NET Web API makes it easy to define endpoints that represent resources, like /api/books or /api/authors, following REST principles.

Example in ASP.NET Web API:

[Route("api/books")]
public class BooksController : ApiController
{
    [HttpGet]
    public IEnumerable<Book> GetBooks()
    {
        // Return a list of books (in JSON format by default)
        return new List<Book> { new Book { Id = 1, Title = "Book One", Author = "Author A" } };
    }

    [HttpPost]
    public IHttpActionResult AddBook(Book newBook)
    {
        // Add a new book to the collection
        return Ok(newBook);
    }
}

In this example, RESTful operations are easily implemented using ASP.NET Web API.

2. ASP.NET

2.1 What is ASP.NET?

ASP.NET is a web application framework developed by Microsoft for building dynamic websites, web services, and web applications. It is part of the .NET platform and allows developers to create robust, scalable, and secure web applications using programming languages like C# and VB.NET.

ASP.NET provides tools and libraries for tasks like:

• Handling HTTP requests and responses
• Managing sessions and user authentication
• Rendering dynamic content (e.g., HTML pages, JSON, etc.)
• Managing data using databases (like SQL Server)
• Supporting modern web development standards (REST APIs, MVC architecture, etc.)

ASP.NET has evolved into two major versions:

1. ASP.NET Framework: The older version that runs on the Windows platform.
2. ASP.NET Core: A cross-platform, open-source framework that can run on Windows, macOS, and Linux.

2.2 Does ASP.NET run on IIS?

ASP.NET can run on IIS (Internet Information Services), Microsoft’s web server for hosting websites and applications on Windows.

1. ASP.NET Framework on IIS:

   • Traditionally, ASP.NET applications (built on the .NET Framework) are designed to run on IIS.
   • IIS provides a hosting environment that integrates closely with ASP.NET, handling incoming HTTP requests and sending responses back to clients.
   • IIS also provides features like process management, request/response handling, authentication, and logging, which are well-suited for running ASP.NET applications.

2. ASP.NET Core on IIS:

   • ASP.NET Core applications can run on IIS, but they don’t require it.
   • By default, ASP.NET Core uses a Kestrel web server, which is a lightweight, cross-platform server. However, you can use IIS as a reverse proxy in front of Kestrel.
   • This configuration allows IIS to manage features like request handling, SSL termination, and load balancing, while Kestrel serves the actual ASP.NET Core app.

2.3 How ASP.NET Core runs on IIS:

• IIS does not directly host the ASP.NET Core app; instead, it acts as a reverse proxy that forwards HTTP requests to the Kestrel server running the ASP.NET Core app.
• The request flow looks like:
  • A client makes an HTTP request to IIS.
  • IIS forwards the request to Kestrel.
  • Kestrel processes the request in the ASP.NET Core application and sends the response back to IIS.
  • IIS then sends the response to the client.

2.4 Benefits of using IIS with ASP.NET:

1. Integration with Windows Server: Full integration with Windows features (e.g., Active Directory, authentication).
2. Request Handling: IIS efficiently handles incoming HTTP requests and ensures the web app is always up.
3. SSL and Security: IIS supports SSL certificates, HTTPS, and security mechanisms like firewalls.
4. Application Pooling: IIS manages application pools that provide isolation for different web apps running on the same server.

Keypoints

• ASP.NET Framework runs directly on IIS.
• ASP.NET Core can run on IIS, but typically uses IIS as a reverse proxy for the Kestrel server.
• While IIS is a great option for hosting on Windows, ASP.NET Core is not tied to IIS and can run on other web servers and platforms, like Nginx, Apache, or directly on Kestrel.

2.5 ASP.NET without IIS

ASP.NET can run without IIS, particularly ASP.NET Core.

1. ASP.NET Core (Cross-Platform, IIS Optional)

ASP.NET Core is designed to be cross-platform and does not require IIS for hosting. By default, ASP.NET Core applications use the Kestrel web server, which is lightweight, cross-platform, and embedded within the application.

Key Points:

• Kestrel: The built-in web server for ASP.NET Core. It runs on all platforms (Windows, Linux, macOS).
• Cross-platform: ASP.NET Core apps can run on Windows, Linux, or macOS without relying on IIS.
• Self-hosted: ASP.NET Core apps can be self-hosted by Kestrel or run behind any reverse proxy like Nginx, Apache, or IIS.

Deployment Scenarios without IIS:

• Directly on Kestrel: For lightweight applications, Kestrel alone can serve web requests without a reverse proxy.
• Nginx or Apache on Linux: In Linux environments, Nginx or Apache can be used as reverse proxies in front of Kestrel, handling things like SSL termination and load balancing, similar to what IIS would do in a Windows environment.
• Docker: ASP.NET Core can run in Docker containers, allowing it to be hosted in any containerized environment without IIS.

Example Configuration:

• Running an ASP.NET Core app on Linux with Nginx:
  • Nginx listens for incoming HTTP requests, forwards them to Kestrel, and returns responses to clients.
  • Kestrel handles the ASP.NET Core app logic and processes requests.

# Install the required dependencies
sudo apt-get install nginx
sudo systemctl start nginx

# Configure Nginx to forward requests to Kestrel
sudo nano /etc/nginx/sites-available/default

# Example Nginx configuration for reverse proxy
server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:5000;  # Kestrel running on port 5000
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

# Restart Nginx to apply changes
sudo systemctl restart nginx

2. ASP.NET Framework (Windows, IIS Required)

The older ASP.NET Framework (non-Core, Windows-only) typically requires IIS for hosting because it is tightly integrated with the Windows ecosystem. However, it is possible to run ASP.NET Framework applications without IIS using self-hosting via tools like OWIN (Open Web Interface for .NET).

• OWIN decouples the web server from the ASP.NET Framework application, allowing it to run in a console application or a Windows service.

Example of Self-Hosting ASP.NET Framework with OWIN:

using Microsoft.Owin.Hosting;
using Owin;
using System;

class Program
{
    static void Main(string[] args)
    {
        // Start OWIN self-hosting on localhost:8080
        using (WebApp.Start<Startup>("http://localhost:8080"))
        {
            Console.WriteLine("Server running at http://localhost:8080/");
            Console.ReadLine(); // Keep the app running
        }
    }
}

class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.Run(context =>
        {
            return context.Response.WriteAsync("Hello from OWIN Self-Hosted App");
        });
    }
}

Tip

• ASP.NET Core: Can run without IIS on Kestrel, Nginx, Apache, or even Docker. It’s platform-independent and can be hosted on Linux, macOS, or Windows.
• ASP.NET Framework: Typically requires IIS for hosting, but self-hosting is possible using OWIN in specific use cases (though this is uncommon for production environments).

2.5 Running ASP.NET in Visual Studio

When you run an ASP.NET application inside Visual Studio, it uses a lightweight, built-in web server called Kestrel or the ASP.NET Development Server (WebDev) depending on the ASP.NET version.

2.5.1 How It Runs Inside Visual Studio

1. Kestrel:

   • Kestrel is a cross-platform web server that is part of the .NET Core runtime. It is used as the default web server for ASP.NET Core applications.
   • When you start an ASP.NET Core project in Visual Studio, it automatically starts the Kestrel server, which listens for incoming HTTP requests.

2. IIS Express:

   • For non-core ASP.NET (i.e., older ASP.NET Framework apps), IIS Express is typically used inside Visual Studio.
   • IIS Express is a lightweight, self-contained version of IIS (Internet Information Services). It allows developers to run ASP.NET applications without needing a full IIS installation.

   IIS Express provides the same web hosting features of IIS but with simpler configuration and fewer security concerns during development.

2.5.2 The Difference Between IIS and IIS Express:

• IIS: This is the full version of Internet Information Services, which is used for hosting web applications on Windows Servers in production environments.
• IIS Express: A lightweight version of IIS, primarily used for development purposes within Visual Studio. It runs locally and doesn’t require the full IIS setup.

Steps for Running an ASP.NET App Inside Visual Studio

1. ASP.NET Core App (Kestrel):

   • When you press F5 or Ctrl + F5 to run the application, Visual Studio launches the Kestrel server and opens the application in your default browser.
   • Kestrel runs as a standalone process that hosts the app.

2. ASP.NET Framework App (IIS Express):

   • For traditional ASP.NET Framework projects, Visual Studio uses IIS Express. It launches IIS Express when you run the app, and the app is served through IIS Express.

   You’ll see the URL in the browser as something like:

   http://localhost:12345/

   where 12345 is the port number dynamically assigned by IIS Express.

Can ASP.NET Work Without IIS?

• ASP.NET Core: Absolutely. You can host an ASP.NET Core app using Kestrel directly or with other web servers (e.g., Nginx or Apache) on Linux, macOS, and Windows.
• ASP.NET Framework: Usually, it relies on IIS or IIS Express because it was originally built for Windows environments. But for development purposes, IIS Express or self-hosting via OWIN (Open Web Interface for .NET) can be used.

Tip

• Inside Visual Studio, ASP.NET Core apps run using Kestrel or IIS Express (for ASP.NET Framework).
• In production, ASP.NET Framework typically uses IIS, while ASP.NET Core can run on Kestrel or other web servers without IIS.

3. Reverse Proxy

A reverse proxy is a server that sits between client requests (e.g., web browsers, mobile apps) and backend servers (e.g., web servers, application servers). It forwards client requests to the appropriate backend server and returns the server’s response to the client.

3.1 Key Roles of a Reverse Proxy

1. Request Forwarding:

   • The reverse proxy receives a client’s request and decides which backend server or service should handle the request. It then forwards the request to that server.

2. Response Forwarding:

   • Once the backend server processes the request and generates a response, the reverse proxy forwards that response back to the client.

3.2 Common Use Cases

1. Load Balancing:

   • A reverse proxy can distribute client requests across multiple backend servers to ensure no single server is overwhelmed. This helps with scalability and fault tolerance.
   • Example: Nginx or IIS can be used to distribute traffic to multiple application instances running an ASP.NET Core app.

2. SSL Termination:

   • The reverse proxy can handle SSL encryption/decryption so that the backend servers don’t have to. This is useful for improving performance and simplifying certificate management.
   • Example: The reverse proxy handles HTTPS traffic, while communication with the backend servers happens over HTTP.

3. Security:

   • Reverse proxies can hide the identity and configuration of backend servers, adding an extra layer of security. They can also filter malicious requests or block certain IP addresses.
   • Example: A reverse proxy may limit access to certain parts of a web app or block denial-of-service (DoS) attacks.

4. Caching:

   • Reverse proxies can cache responses from backend servers to improve performance. Cached responses can be served directly to clients, reducing the load on backend servers.
   • Example: Nginx caching frequently accessed static content (e.g., images, CSS files).

5. Content Compression:

   • The reverse proxy can compress responses (e.g., using Gzip) before sending them to clients, reducing the size of the data transferred and speeding up the user experience.

3.3 Example of Reverse Proxy Setup

• Nginx as a Reverse Proxy for an ASP.NET Core app:
  • The client sends a request to https://example.com.
  • Nginx (the reverse proxy) listens on port 80 or 443 for incoming requests and forwards them to Kestrel (the built-in web server for ASP.NET Core) on port 5000.
  • Kestrel processes the request and sends the response back to Nginx.
  • Nginx then forwards the response to the client.

Nginx Configuration Example:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://localhost:5000;  # Forward requests to Kestrel on port 5000
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3.4 Reverse Proxy vs. Forward Proxy

• Reverse Proxy: Handles requests coming from the client and forwards them to the backend servers. Clients do not need to know about the backend servers.
• Forward Proxy: Typically used by clients to forward requests to external servers (e.g., accessing a website from behind a company firewall). The forward proxy is on the client side, while the reverse proxy is on the server side.

3.5 Common Reverse Proxy Servers:

• Nginx: Often used as a reverse proxy for web applications.
• Apache HTTP Server: Can also act as a reverse proxy.
• IIS: Can be configured to act as a reverse proxy for ASP.NET Core apps.
• HAProxy: A high-performance reverse proxy and load balancer.
• Traefik: A modern reverse proxy and load balancer for microservices and containerized environments.

3.6 Why Use a Reverse Proxy?

• Load balancing and fault tolerance.
• Improved security by hiding internal server details.
• SSL termination to reduce the load on backend servers.
• Caching to reduce backend workload and improve performance.
• Simplified server management, as the reverse proxy can act as a single point of access for multiple services or applications.

4. .Net Remoting (WCF) vs Web API

.NET Remoting and Web API are both mechanisms for enabling communication between different systems, but they are fundamentally different in how they work, their architecture, and their intended use cases.

4.1 .NET Remoting

.NET Remoting is a legacy communication framework in .NET used for intra-application communication over the network, typically within a controlled environment, such as between two .NET applications on different machines.

4.1.1 Key Features of .NET Remoting

• Object-Oriented Communication: .NET Remoting allows the creation of distributed objects. A remote object can be accessed as if it were a local object.
• Binary Protocol: By default, it used a binary formatter for data serialization, making it faster but limited in interoperability (since non-.NET clients cannot easily interpret binary data).
• Tight Coupling: The client and server are tightly coupled. Both sides must have access to the same class definitions and assemblies, making it suitable for homogeneous .NET environments.
• Transport Protocols: Supports TCP and HTTP for transport, and can also work over IPC for local machine communication.
• Serialization: Objects are serialized and transmitted between the client and the server, either using binary or SOAP (XML) formatting.

4.1.2 Limitations

• Platform Dependency: .NET Remoting is specific to .NET and does not easily allow communication with non-.NET clients or platforms.
• Legacy Technology: It’s no longer recommended for new development and is considered a legacy technology, replaced by more modern frameworks like WCF and Web API.
• Complexity: It can be difficult to configure and troubleshoot due to the complexity of object lifetime management and serialization.

4.1.3 Common Use Cases (Historically)

• Communication between .NET applications within a local network or within trusted environments.
• Sharing objects between applications on different machines within a single organization.

---

4.2 Web API (ASP.NET Web API)

ASP.NET Web API is a modern, RESTful framework designed for building HTTP-based services that can be consumed by a wide variety of clients, including web browsers, mobile apps, desktop apps, and other services.

4.2.1 Key Features of Web API:

• RESTful Architecture: Web API adheres to REST principles, meaning it uses standard HTTP methods (GET, POST, PUT, DELETE) for communication, and treats URLs as resources.
• Interoperability: Web API is platform-agnostic. It allows communication with any client (not just .NET) that can send and receive HTTP requests, making it suitable for cross-platform scenarios.
• Text-Based Protocol: Web API typically uses JSON or XML as the data exchange format, making it more human-readable and easier for different platforms to interact with.
• Stateless: It is typically stateless, meaning each request is independent and carries all the necessary information.
• HTTP-Based Communication: It’s built on top of the HTTP protocol, so it’s naturally aligned with web technologies, supports caching, content negotiation, and versioning.
• Lightweight and Scalable: Web APIs are easier to scale across distributed systems and the cloud, as HTTP is a lightweight and scalable protocol.

4.2.2 Common Use Cases:

• Building services that are consumed by web browsers, mobile apps, or other external clients.
• Exposing data and functionality for public use or external integration (e.g., weather data APIs, payment APIs).
• Supporting cross-platform or cross-language communication, as long as the client can make HTTP requests (e.g., JavaScript, Python, Java clients).

---

4.3 Key Differences Between .NET Remoting and Web API

Feature	.NET Remoting	Web API
Communication Type	Object-oriented communication (RPC-style)	HTTP-based, resource-oriented (REST-style)
Coupling	Tight coupling, requires shared object definitions	Loosely coupled, clients only need to understand HTTP and JSON/XML
Data Format	Binary (or SOAP/XML)	JSON, XML, or other formats via HTTP content negotiation
Transport Protocol	TCP, HTTP, IPC	HTTP/HTTPS
Platform Dependency	.NET-specific (limited to .NET clients)	Platform-agnostic (any HTTP client)
Interoperability	Low (limited to .NET clients)	High (can be consumed by any client that can use HTTP)
Use Cases	Intranet, trusted environments	Public APIs, external systems, mobile apps
State Management	Typically stateful	Stateless (each request is independent)
Security	Limited to .NET-based security mechanisms	Supports HTTP security mechanisms (SSL, OAuth, etc.)
Performance	Binary serialization can be fast, but only for .NET	Designed for scalability over HTTP
Current Status	Legacy, no longer recommended for new development	Actively developed and recommended for new applications

---

Keypoints

• .NET Remoting is a legacy technology that is suitable for intra-.NET communication within trusted environments. It has tight coupling and limited interoperability.
• Web API is modern, flexible, and designed for interoperable, HTTP-based communication across platforms, making it ideal for cross-platform services and RESTful APIs.

Tip

For new development, Web API is the preferred choice, especially when you need cross-platform capabilities and loose coupling between services and clients. .NET Remoting is outdated and has been superseded by newer frameworks like WCF (for RPC) and ASP.NET Core Web API (for RESTful services).