Scribd
Upload
7 views39 pages

Chapter 01-Introduction To ASP - Net Core and RESTful Service

The document provides an overview of ASP.NET Core and RESTful services, detailing key concepts such as HTTP, REST principles, and the structure of RESTful web services. It explains the HTTP request and response format, status codes, and the use of HTTP verbs (GET, POST, PUT, DELETE) in web service interactions. Additionally, it discusses the advantages of using .NET for web services and introduces the ControllerBase class, which facilitates the development of ASP.NET Core web applications and services.

Uploaded by

anlthe181137
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
7 views39 pages

Chapter 01-Introduction To ASP - Net Core and RESTful Service

The document provides an overview of ASP.NET Core and RESTful services, detailing key concepts such as HTTP, REST principles, and the structure of RESTful web services. It explains the HTTP request and response format, status codes, and the use of HTTP verbs (GET, POST, PUT, DELETE) in web service interactions. Additionally, it discusses the advantages of using .NET for web services and introduces the ControllerBase class, which facilitates the development of ASP.NET Core web applications and services.

Uploaded by

anlthe181137
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 39

ASP.

NET Core and RESTful Service


Objectives
◆ Hypertext Transfer Protocol
◆ Representational State Transfer (REST)
◆ RESTful Web Service
◆ Introducing ASP.NET Core RESTful Services
◆ ASP.NET Core HTTP Verbs
◆ Controller Actions with RESTful Services
◆ Running OWIN middleware in ASP.NET Core pipeline

2
Hypertext Transfer Protocol (HTTP)
◆ A communications protocol
◆ Allows retrieving inter-linked text documents (hypertext)
▪ World Wide Web.
◆ HTTP Verbs GET /index.html HTTP/1.1
▪ HEAD Host: www.university.edu
Browser Web Server
▪ GET
▪ POST
▪ PUT HTTP/1.1 200 OK
Content-Type: text/html
▪ DELETE
▪ TRACE <html><head>…
▪ OPTIONS
▪ CONNECT
3
HTTP Request-response format
◆ Request consists of
▪ Request line, such as GET /images/logo.gif HTTP/1.1, which requests a
resource called /images/logo.gif from server.
▪ Headers, such as Accept-Language: en
▪ An empty line
▪ An optional message body
◆ Response consists of
▪ Status line which includes numeric status code and textual reason
phrase
▪ Response headers
▪ An empty line
▪ The requested content
4
HTTP Request Components
◆ URL: Each Request must have a unique URL
◆ Verb (Method): Each Request must have an HTTP Verb.
◆ Header(s): Each Request can contain one or more Headers.
◆ Body: Each request can have a body. The body contains the data that we want to
send to the server.

5
HTTP Response Components
◆ HTTP Status Code: It must have a Status Code.
◆ Response Headers: It can have one or more response headers.
◆ Data: Response can have data i.e. return to the client.

6
HTTP Status Codes
◆ The Status code is issued from the server and they give information about the
response.
◆ 1XX: Informational Response
◆ 2XX: Successful, whenever you get 2XX as the response code, it means the request
is successful.
◆ 3XX: Redirection, whenever you get 3XX as the response code, it means it is re-
directional i.e. some re-directional is happening on the server.
◆ 4XX: Client Error, whenever you get 4XX as the response code, it means there is
some problem with your request.
◆ 5XX: Server Error. Whenever you get 5XX as the response code, it means there is
some problem in the server.

7
REST
◆ REST stands for Representational State Transfer
◆ It is an architectural pattern for developing web services as opposed to a specification
◆ REST web services communicate over the HTTP specification, using HTTP
vocabulary
▪ Methods (GET, POST, etc.)
▪ HTTP URI syntax (paths, parameters, etc.)
▪ HTTP Response codes.
▪ Media types (xml, json, html, plain text, etc)

8
SOAP: Simple Object Access Protocol
◆ A protocol specification for exchanging structured information in the implementation
of Web Services. It defines a standard message format.
◆ Purpose: Designed for robust, standardized communication, often in enterprise
environments. Ensures interoperability between applications built on different
platforms/languages.
◆ Key characteristics:
▪ XML-Based: All SOAP messages must be formatted in XML.
▪ Standards-Driven: Relies heavily on related WS-* standards (Web Services
Specifications) like WSDL (Web Services Description Language), WS-Security
▪ Transport Independent: Can operate over various protocols (HTTP, SMTP, TCP,
etc.), although HTTP/HTTPS is the most common.

9
Major REST principles - 1
◆ Information is organized in the form of resources
▪ Sources of specific information,
▪ Referenced with a global identifier (e.g., a URI in HTTP).

◆ Components of the network (user agents and origin servers) communicate via a
standardized interface (e.g., HTTP)
▪ exchange representations of these resources (the actual documents conveying the
information).

10
Major REST principles - 2
◆ Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate
the request, but each does so without being concern about anything but its own
request
▪ an application can interact with a resource by knowing two things: the identifier of
the resource and the action required
▪ no need to know whether there are caches, proxies, gateways, firewalls, tunnels, or
anything else between it and resource
▪ The application needs to understand the format of the information (representation)
returned.

11
Characteristics of a REST based network
◆ Client-Server: a pull-based interaction style(Client request data from servers as and
when needed).
◆ Stateless: each request from client to server must contain all the information
necessary to understand the request, and cannot take advantage of any stored
context on the server.
◆ Cache: to improve network efficiency, responses must be capable of being labeled as
cacheable or non-cacheable.
◆ Uniform interface: all resources are accessed with a generic interface (e.g., HTTP
GET, POST, PUT, DELETE).
◆ Named resources - the system is comprised of resources which are named using a
URL.
◆ Interconnected resource representations - the representations of the resources are
interconnected using URLs, thereby enabling a client to progress from one state to
another.
12
RESTful Web Service definition
◆ A RESTful Web service is:
▪ A set of Web resources.
▪ Interlinked.
▪ Data-centric, not functionality-centric.
▪ Machine-oriented.

◆ Like Web applications, but for machines.


◆ Like WS-*, but with more Web resources (WS-* stands for a variety of
specifications related to SOAP-based Web Services).

13
Principles of RESTful web service design - 1
1. Identify all the conceptual entities that we wish to expose as services. (Resources
such as : parts list, detailed part data, purchase order)
2. Create a URL to each resource.
3. Categorize our resources according to whether clients can just receive a
representation of the resource (using an HTTP GET), or whether clients can modify
(add to) the resource using HTTP POST, PUT, and/or DELETE).
4. All resources accessible via HTTP GET should be side-effect free. That is, the
resource should just return a representation of the resource. Invoking the resource
should not result in modifying the resource.

14
Principles of RESTful web service design - 2
5. Put hyperlinks within resource representations to enable clients to drill down for
more information, and/or to obtain related information.
6. Design to reveal data gradually. Don't reveal everything in a single response
document. Provide hyperlinks to obtain more details.
7. Specify the format of response data using a schema (DTD, W3C Schema,
RelaxNG, or Schematron). For those services that require a POST or PUT to it, also
provide a schema to specify the format of the response.
8. Describe how our services are to be invoked using either a WSDL document, or
simply an HTML document.

15
SOAP vs. REST - Key Differences
Feature SOAP REST (Representational State Transfer)
Type Protocol Specification Architectural Style
Data Format Strictly XML Flexible (JSON, XML, YAML, Text, etc.) - JSON is
dominant
Transport Independent (HTTP, SMTP, Primarily HTTP/HTTPS
TCP...)
Standardization Heavy reliance on WS-* Leverages existing HTTP standards (Verbs: GET,
standards (WSDL, WS-Security, POST, PUT, DELETE; Status Codes: 200, 404, 500;
etc.) URIs; Caching)
State Can be stateful Primarily Stateless
Management
Security Comprehensive standards (WS- Relies on Transport Layer Security (HTTPS) and
Security) application-level security (e.g., OAuth, JWT)
Bandwidth Generally higher (XML verbosity, Generally lower (especially with JSON)
Usage envelope overhead)
Error Handling Standardized <Fault> element in Uses HTTP Status Codes; error details often in
Body response body (format varies)

16
Introducing ASP.NET Core RESTful Services
◆ ASP.NET Web API, from the beginning, was designed to be a service-based
framework for building REpresentational State Transfer (RESTful) services.
◆ It is based on the MVC framework minus the V (view), with optimizations for creating
headless services.
◆ Calls to a Web API service are based on the core HTTP verbs (Get, Put,
Post, Delete) through a uniform resource identifier (URI).
◆ Calls to Web API use the Hypertext Transfer Protocol (HTTP) scheme on a particular
host on a specific port, followed by the path and an optional query and fragment.

17
Reasons for choosing .NET for Web Services - 1
Use .NET for your server application or service when:
◆ You have cross-platform needs.
▪ If your web or service application needs to run on multiple platforms, for example,
Windows, Linux, and macOS, use .NET.
◆ You're targeting microservices.
▪ A microservices architecture allows a mix of technologies across a service
boundary. This technology mix enables a gradual embrace of .NET for new
microservices that work with other microservices or services.
◆ You need side-by-side .NET versions per application.
▪ This side-by-side installation allows multiple services on the same server, each of
them on its own version of .NET.
18
Reasons for choosing .NET for Web Services - 2
Use .NET for your server application or service when:
◆ You're using Docker containers.
▪ Containers are commonly used in conjunction with a microservices architecture.
Containers can also be used to containerize web apps or services that follow any
architectural pattern. .NET Framework can be used on Windows containers, but the
modularity and lightweight nature of .NET makes it a better choice for containers.
◆ You need high-performance and scalable systems.
▪ When your system needs the best possible performance and scalability, .NET and
ASP.NET Core are your best options. The high-performance server runtime for
Windows Server and Linux makes ASP.NET Core a top performing web framework
on TechEmpower benchmarks
19
07/01/2025 20
ControllerBase Class

The ControllerBase class provides the core functionality for both ASP.NET Core
web applications and services, in addition to helper methods for returning
HTTP status codes and properties
 Some of the Properties provided by the ControllerBase Class:
Properties Description
HttpContext Returns the HttpContext for the currently executing action
Request Returns the HttpRequest for the currently executing action
Response Returns the HttpResponse for the currently executing action

ModelState Returns the state of the model in regard to model binding and validation
Url Returns an instance of the IUrlHelper, providing access to building URLs for ASP.NET MVC
Core applications and services
RouteData Returns the RouteData for the currently executing action
07/01/2025 21
ControllerBase Class

Some of the Helper Methods provided by the ControllerBase Class:
Method Notes

BadRequest Returns 400 status code


NotFound Returns 404 status code
PhysicalFile Returns a file
TryUpdateModelAsync Invokes model binding
TryValidateModel Invokes model validation
NoContent Creates a NoContentResult object that produces an empty Status204NoContent response
Ok Creates a OkResult object that produces an empty Status200OK response
Accepted() Creates a AcceptedResult object that produces an Status202Accepted response
Content(String) Creates a ContentResult object by specifying a content string
07/01/2025 22
Request and Response

A REST request generally consists of the following:
 HTTP verb: This denotes what kind of operation the requests want to perform on the
server
 Header: This element of the REST request allows the client to pass more
information about the request
 URL: The actual path to the resource that the REST request wants to operate on
 Body: The body can contain extra data related to a resource to identify or update it.
This is optional though

07/01/2025 23
HTTP verbs

The following are basic HTTP verbs used while requesting a REST system for
resource interaction:
 GET: Used to retrieve a specific resource by its identity or a collection of resources
 POST: Used to create/insert a new resource
 PUT: Used to update a specific resource by its identity
 DELETE: Used to remove a specific resource by its identity

07/01/2025 24
Status Code

When a server returns responses, it includes status codes. These status
codes inform the client how the request performed on the server
Status Code Explanation
200 OK Standard response for successful HTTP requests
201 CREATED Standard response for an HTTP request when an item is successfully
NO CONTENT Standard response for successful HTTP requests, if nothing is
204
returned in the response body
400 BAD Request cannot be processed because of bad request syntax, excessive size, or
REQUEST another client error
403 FORBIDDEN Client does not have permission to access the requested resource
Resource could not be found at this time. It might have been deleted, or does not
404 NOT FOUND
exist yet
500 INTERNAL This response comes whenever there is a failure or exception happens while
SERVER ERROR processing the server side codes
07/01/2025 25
First ASP.NET Core Web API Project

26
ASP.NET Core attributes

The Microsoft.AspNetCore.Mvc namespace provides attributes that can be
used to configure the behavior of web API controllers and action methods

The following example uses attributes to specify the supported HTTP action
verb and any known HTTP status codes that could be returned:
[HttpPost]
[ProducesResponseType(StatusCodes.Status201Created)]
[ProducesResponseType(StatusCodes.Status400BadRequest)]
public ActionResult<Product> Create(Product product)
{
//………
return CreatedAtAction(nameof(GetById), new { id = product.Id },
product);
} 07/01/2025 27
ASP.NET Core attributes

Some more examples of attributes that are available:
Method Notes
HttpPostAttribute Identifies an action that supports the HTTP POST method
HttpPutAttribute Identifies an action that supports the HTTP PUT method
HttpDeleteAttribute Identifies an action that supports the HTTP DELETE method
HttpGetAttribute Identifies an action that supports the HTTP GET method
RouteAttribute Specifies an attribute route on a controller
HttpHeadAttribute Identifies an action that supports the HTTP HEAD method
HttpOptionsAttribute Identifies an action that supports the HTTP OPTIONS method
HttpPatchAttribute Identifies an action that supports the HTTP PATCH method

More attributes: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc?view=aspnetcore-5.0

07/01/2025 28
ASP.NET Core attributes

07/01/2025 29
Binding Source Parameter Inference

A binding source attribute defines the location at which an action parameter's
value is found

The following binding source attributes exist:
Attribute Binding source

[FromBody] Inferred for complex types. Only one FromBody parameter can exist or an exception will be thrown. Exceptions
exist for IFormCollection and CancellationToken
[FromForm] Inferred for action parameters of type IFormFile and IFormFileCollection. When parameter is marked with
FromForm, the multipart/form-data content type is inferred
[FromHeader] Request header

[FromQuery] Inferred for any other action parameters

[FromRoute] Inferred for any parameter name that matches a route token name

[FromServices] The request service injected as an action parameter

07/01/2025 30
Binding Source Parameter Inference

07/01/2025 31
ASP.NET Core HTTP Verbs - 1
◆ GET - As the name specifies, this verb is used to retrieve the data or information. It
does not have any other effect except getting data.

◆ POST - This verb is used to generate or create the resource. For example, If we have
to add some information to the database then we must define the method as a POST
method. The most common form to submit the data into the POST method is to pass
the data into any entity object.

32
ASP.NET Core HTTP Verbs - 2
◆ PUT - This verb is used to update the existing resource. For example, If we have to
update some information to the database then we can define the method as a PUT
method. We can send the data in the form of object as well as in a parameter

◆ DELETE - This verb is used to delete the existing resource. For example, If we have
to delete some information to the database then we can define the method as a
DELETE method. We can send the data in the form of object as well as in a parameter
too. too.

33
Controller Actions with RESTful Services
◆ APIs also use HTTP status codes to communicate success or failure.

◆ Formatted JSON Response Results

34
The ApiController Attribute
◆ Attribute Routing Requirement
▪ When using the ApiController attribute, the controller must use attribute routing.
◆ Automatic 400 Responses
▪ ASP.NET Core uses the ModelStateInvalidFilter action filter to do the preceding
check. When there is a binding or a validation error, the HTTP 400 response in the
body includes details for the errors.

▪ This behavior can be disabled through configuration in the ConfigureServices()

35
Binding Source Parameter Inference

◆ This behavior can be disabled through configuration in the ConfigureServices()


method.

36
Problem Details for Error Status Codes
◆ ASP.NET Core transforms an error result (status of 400 or higher) into a result with
ProblemDetails.

37
Building API Action Methods
◆ The Constructor
◆ The Get Methods
◆ The UpdateOne Method
◆ The AddOne Method
◆ The DeleteOne Method

38
Summary
Concepts were introduced:
◆ Hypertext Transfer Protocol
◆ Representational State Transfer (REST)
◆ SOAP vs. REST - Key Differences
◆ RESTful Web Service
◆ Introducing ASP.NET Core RESTful Services
◆ ASP.NET Core HTTP Verbs
◆ Controller Actions with RESTful Services
◆ Running OWIN middleware in ASP.NET Core pipeline

39

You might also like