Skip to content

01 - Intro

Typical application architecture

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
┌──────────────────────────────────┐
│                                  │
│                                  │
│           Application            │
│                                  │
│                                  │
└──────────────────────────────────┘
┌──────────────────────────────────┐
│                                  │
│                                  │
│             Database             │
│                                  │
│                                  │
└──────────────────────────────────┘

Modern Web application architecture (N-Tier)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
┌─────────────────────┐
│                     │
│    Application      │
│    JS/iOS/...       │
└─────────────────────┘
┌─────────────────────┐   ┌────────────────────┐
│                     │   │                    │
│    Service/API      │   │     Application    │
│    Rest API/Dist    │   │     ASP.NET WEB    │
└─────────────────────┘   └────────────────────┘
┌──────────────────────────────────────────────┐
│                                              │
│            Business Logic Layer              │
│                 BLL/Services                 │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│                                              │
│              Data Access Layer               │
│              UOW/Repositories                │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│                                              │
│                  Database                    │
│                                              │
└──────────────────────────────────────────────┘

Clean Architecture

Clean

Clean architecture is a software design philosophy that separates the elements of a design into ring levels. An important goal of clean architecture is to provide developers with a way to organize code in such a way that it encapsulates the business logic but keeps it separate from the delivery mechanism.

Clean Architecture is a software architecture intended to keep the code under control without all tidiness that spooks anyone from touching a code after the release. The main concept of Clean Architecture is the application code/logic which is very unlikely to change, has to be written without any direct dependencies. So it means that if you change the database, or UI, the core of the system (Business Rules/ Domain) should not be changed. It means external dependencies are completely replaceable.

Why services?

  • Database changes, underlaying business rules change
  • Data access is expensive
  • Possibility to divide functionality between different platforms
  • Future proof (versioning)
  • Authentication and authorization

WebService

Today, the principal use of the World Wide Web is for interactive access to documents and applications. In almost all cases, such access is by human users, typically working through Web browsers, audio players, or other interactive front-end systems. The Web can grow significantly in power and scope if it is extended to support communication between applications, from one program to another.

-- Source: W3C XML Protocol Working Group Charter

Laiemas mõttes tähendab "veebiteenus" nö harilikku veebi, selle erinevusega, et urlide avamist ja vormide täitmist teeb programm, ning tulemusi loeb ja kasutab samuti programm, mitte inimene. Teisisõnu, "veebiteenus" tähendab programmide omavahelist suhtlemist ja andmevahetust üle hariliku veebi.

-- Tanel Tammet

HTTP - GET

HTTP is purely text-based protocol, basically you are just sending bunch of key-value pairs from browser to server

  • Request
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
GET https://localhost:44363/People/Create HTTP/1.1
Host: localhost:44363
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://localhost:44363/People
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,et;q=0.8
Cookie: _ga=GA1.1.1433392067.1524809543;
  • Response
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-SourceFiles: =?UTF-8?B?QzpcVXNlcnNcYWthdmVyXHNvdXJjZVxyZXBvc1xIVFRQVGVzdFxXZWJBcHBcUGVvcGxlXENyZWF0ZQ==?=
X-Powered-By: ASP.NET
Date: Sat, 26 Jan 2019 12:24:13 GMT
Content-Length: 3367

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Create - WebApp</title>

HTTP - POST

  • Request
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
POST https://localhost:44363/People/Create HTTP/1.1
Host: localhost:44363
Connection: keep-alive
Content-Length: 194
Cache-Control: max-age=0
Origin: https://localhost:44363
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: https://localhost:44363/People/Create
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,et;q=0.8
Cookie: _ga=GA1.1.1433392067.1524809543; 

Name=Andres&__RequestVerificationToken=CfDJ8JXfYWVYzpxPgG_38dOFAzHQGkoaDtNMXtzBr3vNUFUDOYe7XT_ueh6IMyEfRXYWTTOvd2Bjm8gxjOwN8jRBGngeIIKZmnJB-xD4Wvd1enqy0M5GrgAWVgAOg0vZPgHNzvIYDBTmwJqi3L2WYM-5mm4
  • Response
1
2
3
4
5
6
7
HTTP/1.1 302 Found
Location: /People
Server: Microsoft-IIS/10.0
X-SourceFiles: =?UTF-8?B?QzpcVXNlcnNcYWthdmVyXHNvdXJjZVxyZXBvc1xIVFRQVGVzdFxXZWJBcHBcUGVvcGxlXENyZWF0ZQ==?=
X-Powered-By: ASP.NET
Date: Sat, 26 Jan 2019 12:17:16 GMT
Content-Length: 0

Response codes

  • 1xx Informational response
    • 100 continue
    • 101 switching protocols
  • 2xx Success
    • 200 OK
    • 201 Created
    • 202 Accepted
    • 204 No Content
  • 3xx Redirection
    • 300 Multiple choices
    • 301 Moved Permanently
    • 302 Found
    • 303 See other
    • 304 Not Modified
  • 4xx Client errors
    • 400 Bad Request
    • 401 Unauthorized
    • 403 Forbidden
    • 404 Not Found
    • 409 Conflict
  • 5xx Server errors
    • 500 Internal Server Error
    • 501 Not implemented
    • 503 Service Unavailable

RESTful service/api

REST - Representational State Transfer

It’s an architectural style that defines a set of recommendations for designing loosely coupled applications that use the HTTP protocol for data transmission. REST doesn’t prescribe how to implement the principles at a lower level. Instead, the REST guidelines allow developers to implement the details according to their own needs. Web services built following the REST architectural style are called RESTful web services.

  • Uniform interface Requests from different clients should look the same, for example, the same resource shouldn’t have more than one URI.

  • Client-server separation The client and the server should act independently. They should interact with each other only through requests and responses.

  • Statelessness There shouldn’t be any server-side sessions. Each request should contain all the information the server needs to know.

  • Cacheable resources Server responses should contain information about whether the data they send is cacheable or not. Cacheable resources should arrive with a version number so that the client can avoid requesting the same data more than once.

  • Layered system There might be several layers of servers between the client and the server that returns the response. This shouldn’t affect either the request or the response.

Code on demand [optional]

When it’s necessary, the response can contain executable code (e.g., JavaScript within an HTML response) that the client can execute.

REST vs SOAP

  • REST makes data available as resources (e.g. user)
  • SOAP makes data available via services (e.g. getUser)

SOAP – Simple Object Access Protocol

  • SOAP can work with any application layer protocol, such as HTTP, SMTP, TCP, or UDP. It returns data to the receiver in XML format (usually). Security, authorization, and error-handling are built into the protocol.

  • Currently, SOAP will likely continue to be used for big enterprise-level web services that require high security and complex transactions. APIs for financial services, goverment, payment gateways, CRM software, identity management, and telecommunication services are commonly used examples of SOAP.

  • One of the most well-known SOAP APIs is PayPal’s public API that allows you to accept PayPal and credit card payments, add a PayPal button to your website, let users log in with PayPal, and perform other PayPal-related actions.
  • Estonian SOAP services: X-Tee, DigiDoc, EMTA

SOAP Example - EMTA VAT Registry WDSL - automatic description of accessible methods and data structures used.

Open-API example swagger

What will we do?

We will start with REST based services as more modern approach.
At the end of semester (if time permits), some SOAP and XML.

Good reading: How I Explained REST to My Wife
http://web.archive.org/web/20130116005443/http://tomayko.com/writings/rest-to-my-wife

NB! Tooling

Tooling needed at first

  • .NET 8 SDK and ASP.NET Core
  • JetBrains Rider – Main IDE
  • Postman – for REST testing
  • Node and NPM – for frontend client development
  • JS frontend framework (Angular, Aurelia, ...) or not-so-full-framework (React, Vue, Svelte) or use barebones approach and write plain JS (and maybe some jQuery)
  • TypeScript on top of JS is a must

Demo

One entity single list app