lectio

Introduction

Contents

• Azure
  • Core Concepts
    • Resource Group
    • Resource
    • Tags
  • CLI
• REST Architecture
  • REST over HTTP
    • Maturity Model
    • Hypertext as the Engine of Application State (HATEOAS)
• Azure Cognitive Services
  • Categories
• References
• Agenda

Azure

Core Concepts

In the following we will introduce some key concepts of Azure. In the references section you can find the links to the official Microsoft documentation with screenshots and samples.

Resource Group

A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. You decide how you want to allocate resources to resource groups based on what makes the most sense for your organization. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.

Resource

A resource is a manageable item that is available through Azure. Virtual machines, storage accounts, web apps, databases, and virtual networks are examples of resources. Resource groups, subscriptions, management groups, and tags are also examples of resources.

Tags

You apply tags to your Azure resources, resource groups, and subscriptions to logically organize them into a taxonomy. Each tag consists of a name and a value pair. For example, you can apply the name “Environment” and the value “Production” to all the resources in production.

CLI

The Azure command-line interface (Azure CLI) is a set of commands used to create and manage Azure resources. The Azure CLI is available across Azure services and is designed to get you working quickly with Azure, with an emphasis on automation.

The Azure CLI is available to install in Windows, macOS and Linux environments. It can also be run in a Docker container and Azure Cloud Shell.

REST Architecture

Representational State Transfer (REST) is an architectural style that specifies constraints, such as the uniform interface, that if applied to a web service induce desirable properties, such as performance, scalability, and modifiability, that enable services to work best on the Web. In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web. The resources are acted upon by using a set of simple, well-defined operations. The REST architectural style constrains an architecture to a client/server architecture and is designed to use a stateless communication protocol. In the REST architecture style, clients and servers exchange representations of resources by using a standardized interface and protocol.

The following principles encourage RESTful applications to be simple, lightweight, and fast:

• Resource identification through URI: A RESTful web service exposes a set of resources that identify the targets of the interaction with its clients.

• Uniform interface: Resources are manipulated using a fixed set of operations.

• Self-descriptive messages: Resources are decoupled from their representation so that their content can be accessed in a variety of formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others. Metadata about the resource is available and used, for example, to control caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access control.

• Stateful interactions through hyperlinks: Every interaction with a resource is stateless; that is, request messages are self-contained. Stateful interactions are based on the concept of explicit state transfer. Several techniques exist to exchange state, such as URI rewriting, cookies, and hidden form fields. State can be embedded in response messages to point to valid future states of the interaction.

REST over HTTP

In 2000, Roy Fielding proposed Representational State Transfer (REST) as an architectural approach to designing web services. REST is an architectural style for building distributed systems based on hypermedia. REST is independent of any underlying protocol and is not necessarily tied to HTTP. However, most common REST implementations use HTTP as the application protocol, and this guide focuses on designing REST APIs for HTTP.

Here are some of the main design principles of RESTful APIs using HTTP:

• REST APIs are designed around resources, which are any kind of object, data, or service that can be accessed by the client.
• A resource has an identifier, which is a URI that uniquely identifies that resource.
• Clients interact with a service by exchanging representations of resources. Many web APIs use JSON as the exchange format.
• REST APIs use a uniform interface, which helps to decouple the client and service implementations. For REST APIs built on HTTP, the uniform interface includes using standard HTTP verbs to perform operations on resources. The most common operations are GET, POST, PUT, PATCH, and DELETE.
• REST APIs use a stateless request model. HTTP requests should be independent and may occur in any order, so keeping transient state information between requests is not feasible. The only place where information is stored is in the resources themselves, and each request should be an atomic operation. This constraint enables web services to be highly scalable, because there is no need to retain any affinity between clients and specific servers.
• REST APIs are driven by hypermedia links that are contained in the representation.

Maturity Model

In 2008, Leonard Richardson proposed the following maturity model for web APIs:

• Level 0: Define one URI, and all operations are POST requests to this URI.
• Level 1: Create separate URIs for individual resources.
• Level 2: Use HTTP methods to define operations on resources.
• Level 3: Use hypermedia (HATEOAS).

Hypertext as the Engine of Application State (HATEOAS)

One of the primary motivations behind REST is that it should be possible to navigate the entire set of resources without requiring prior knowledge of the URI scheme. Each HTTP GET request should return the information necessary to find the resources related directly to the requested object through hyperlinks included in the response, and it should also be provided with information that describes the operations available on each of these resources. This principle is known as HATEOAS, or Hypertext as the Engine of Application State. The system is effectively a finite state machine, and the response to each request contains the information necessary to move from one state to another; no other information should be necessary.

Azure Cognitive Services

Categories

• Vision
• Speech
• Language
• Search
• Decision

References

• Azure
  • Core Concepts:
    • Resource Groups:
      • https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal
      • https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resources-cli
    • Resources:
      • https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/overview
      • https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resources-portal
      • https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resources-cli
    • Tags:
      • https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources
  • CLI:
    • https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest
    • https://docs.microsoft.com/en-us/cli/azure/what-is-azure-cli?view=azure-cli-latest
    • https://docs.microsoft.com/en-us/cli/azure/get-started-with-azure-cli?view=azure-cli-latest
• REST Architecture:
  • https://en.wikipedia.org/wiki/Representational_state_transfer
  • https://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
  • https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
• Swagger: https://swagger.io/

Agenda

1. Presentation (00:00)
2. Introduction
3. Azure Cognitive Services 15:00
4. Telegram Bot with Go
5. Vision (01:00)
6. Language (01:30)
7. Decision
8. Q&A (01:55)