endpoints_2
This commit is contained in:
parent
2a118a0015
commit
ac4298bde8
@ -1,21 +1,21 @@
|
||||
:root {
|
||||
/* light theme */
|
||||
/* --color-bg: #e0e0e0; */
|
||||
--color-bg: #fff5ee;
|
||||
--color-bg: #fefefe;
|
||||
--color-fg: #1c1c1c;
|
||||
|
||||
--color-anchor-bg: unset;
|
||||
--color-anchor-fg: black;
|
||||
|
||||
--color-kbd-bg: beige;
|
||||
--color-kbd-bg: #f9f9f9;
|
||||
--color-kbd-fg: var(--color-fg);
|
||||
--color-kbd-border: lightgray;
|
||||
|
||||
--color-codeblock-bg: beige;
|
||||
--color-codeblock-bg: #f9f9f9;
|
||||
--color-codeblock-fg: var(--color-fg);
|
||||
--color-codeblock-border: lightgray;
|
||||
|
||||
--color-code-bg: beige;
|
||||
--color-code-bg: #f9f9f9;
|
||||
--color-code-fg: var(--color-fg);
|
||||
--color-code-border: lightgray;
|
||||
|
||||
@ -36,8 +36,8 @@
|
||||
--paragraph-size: 18px;
|
||||
--paragraph-spacing: 18px;
|
||||
|
||||
--article-width: 1000px;
|
||||
--article-width: 950px;
|
||||
--article-font-size: 18px;
|
||||
--article-line-height: 1.8em;
|
||||
--article-line-height: 1.9em;
|
||||
--article-spacing: 16px;
|
||||
}
|
||||
@ -8,6 +8,10 @@
|
||||
import BrowserNetwork from "../../assets/img/43_browser_network.png";
|
||||
</script>
|
||||
|
||||
<svelte:head>
|
||||
<title>Criando e executando endpoints</title>
|
||||
</svelte:head>
|
||||
|
||||
<section>
|
||||
<h1>Criando e executando endpoints</h1>
|
||||
|
||||
@ -16,12 +20,8 @@
|
||||
</nav>
|
||||
|
||||
<p>
|
||||
Enfim, vamos escrever nossos primeiros <em>endpoints</em>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Durante este capitulo, vamos trabalhar somente em <code>Biblioteca/Program.cs</code>. Nosso objetivo por enquanto é escrever um endpoint customizado, e testar se ele
|
||||
responde corretamente, da forma como desejamos.
|
||||
Neste capítulo, vamos escrever o nosso primeiro <em>endpoint</em>. Iremos trabalhar somente no arquivo <code>Biblioteca/Program.cs</code>. Nosso objetivo por enquanto é escrever um endpoint, e testar se ele
|
||||
responde corretamente.
|
||||
</p>
|
||||
|
||||
<section>
|
||||
|
||||
@ -2,6 +2,10 @@
|
||||
|
||||
</script>
|
||||
|
||||
<svelte:head>
|
||||
<title>Definindo os endpoints da Biblioteca</title>
|
||||
</svelte:head>
|
||||
|
||||
<section>
|
||||
<h1>Definindo os endpoints da Biblioteca</h1>
|
||||
|
||||
@ -10,7 +14,7 @@
|
||||
</nav>
|
||||
|
||||
<p>
|
||||
Como definimos <a href="/projeto_de_api" target="_blank">anteriormente</a>, o escopo do nosso projeto determina que nós devemos fazer um sistema onde seja possível:
|
||||
Como definimos <a href="/projeto_de_api" target="_blank">anteriormente</a>, o escopo do nosso projeto determina que nós devemos escrever uma API REST onde seja possível:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
@ -20,15 +24,130 @@
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
Para tanto, devemos criar, então, os <em>endpoints</em> necessários para que o nosso sistema seja capaz de realizar estas ações.
|
||||
Para tanto, devemos criar, então, os <em>endpoints</em> necessários para que o nosso sistema seja capaz de realizar estas ações. Mas antes de tudo, vamos recapitular o que é uma API e
|
||||
o que é o protocolo REST.
|
||||
</p>
|
||||
|
||||
<section>
|
||||
<h2>Verbos, URIs e REST</h2>
|
||||
<h2>O que é uma API</h2>
|
||||
|
||||
<p>
|
||||
No capítulo anterior, criamos um endpoint simples que responde à <em>requisições HTTP</em>
|
||||
Uma <a href="https://en.wikipedia.org/wiki/API" target="_blank">API</a> (Application Program Interface) é uma interface de comunicação entre softwares.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Pense em uma interface de usuário. Uma interface de usuário serve como meio de comunicação entre o usuário e o software. Já uma API é um meio de comunicação entre softwares.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Você utiliza APIs constantemente quando escreve um programa. Quando você utiliza alguma função da
|
||||
<a href="https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0" target="_blank">biblioteca padrão</a> da sua linguagem
|
||||
favorita, você está consumindo uma API.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Por exemplo, o C# tem uma API para a manipulação da entrada e saída de um programa que é executado em um terminal:
|
||||
a classe <code><a href="https://learn.microsoft.com/pt-br/dotnet/api/system.console?view=net-8.0" target="_blank">System.Console</a></code>.
|
||||
Quando você usa <code><a href="https://learn.microsoft.com/pt-br/dotnet/api/system.console.writeline?view=net-8.0" target="_blank">Console.WriteLine</a></code>
|
||||
para exibir um "Hello World!" no terminal, você não precisa se preocupar com as operações necessárias para mostrar uma mensagem no console. Você apenas chama o método com a mensagem que quer exibir. Estes detalhes internos são <em>abstraídos</em> para você em uma
|
||||
única chamada de um método. APIs são formas de criar <em>abstrações</em> de funcionalidades.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Se você precisasse desenvolver um sistema desktop, como você o faria? Para criar uma janela no windows, você precisaria utilizar as APIs do <a href="https://learn.microsoft.com/pt-br/windows/win32/desktop-programming" target="_blank">Win32</a>.
|
||||
No linux, há o <a href="https://www.x.org/wiki/Documentation/" target="_blank">X.Org</a> e o <a href="https://wayland.freedesktop.org/docs/html/" target="_blank">Wayland</a>. Você gostaria que sua aplicação fosse multiplataforma, mas para isso você teria que escrever códigos diferentes que utilizariam cada API de cada sistema operacional. Você poderia pesquisar uma biblioteca ou framework que facilita esse processo, abstraindo os detalhes internos de cada API nativa dos sistemas operacionais em uma única API, como o <a href="https://www.qt.io/">Qt</a>. Seu progama, então, utiliza este framework para mostrar uma interface, que por sua vez, internamente, utiliza as APIs nativas do sistema operacional onde o seu software está sendo executado. Já os sistemas operacionais utilizam as APIs do seu driver de vídeo para exibir as janelas no seu monitor, do controlador USB para ler o teclado e mouse, entre outros. Ou seja, com APIs podemos criar várias camadas de abstração. Todo o ambiente em um computador é composto por softwares comunicando-se uns com os outros, utilizando estas abstrações, através de APIs.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Há inúmeras formas de se montar uma API. Nos exemplos anteriores, isso acontece através de bibliotecas. Formas de <a href="https://en.wikipedia.org/wiki/Inter-process_communication" target="_blank">comunicação inter-processo</a>, como sockets, também podem ser
|
||||
utilizadas. Desta forma, podemos utilizar também protocolos de rede, como o próprio HTTP. Uma API que funciona no protocolo HTTP é uma <a href="https://en.wikipedia.org/wiki/Web_API" target="_blank">API Web</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Como o HTTP é um protocolo de rede para a comunicação entre dois computadores distintos, o software que consome a API e o que a disponibiliza não precisam estar no mesmo computador. Temos, então, um sistema <em>distribuído</em> ou <em>descentralizado</em>.
|
||||
</p>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<h2>O padrão REST</h2>
|
||||
|
||||
<p>
|
||||
O <a href="https://developer.mozilla.org/pt-BR/docs/Glossary/REST" target="_blank">REST</a> é um padrão arquitetural para aplicações em rede que utilizam o protocolo HTTP. Este padrão impõe algumas restrições para o desenho de APIs Web de forma a melhorar a qualidade e a confiabilidade.
|
||||
Este padrão foi descrito em 2000 na <a href="https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf" target="_blank">dissertação de PHD</a> de Roy Fielding e é ubíquo até hoje na arquitetura de sistemas Web.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
REST significa Representational State Transfer (transferência de estado representacional). Podemos entendê-lo, de uma forma muito simplificada (e que não compreende todo o padrão como foi escrito na dissertação), como
|
||||
uma série de regras para usarmos o protocolo HTTP para acessar ou manipular recursos em um servidor, onde o identificador do recurso é a URI, o verbo HTTP define a ação que se deseja realizar sobre o recurso, o status de resposta
|
||||
(status code) define o estado da operação, e o conteúdo (corpo) da mensagem é a <em>representação do recurso</em>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Voltando ao escopo da API que queremos desenvolver, nós queremos visualizar os livros disponíveis na biblioteca. Para isso, utilizando o padrão REST, podemos criar alguns endpoints como:
|
||||
</p>
|
||||
|
||||
<pre><code>{`GET /livros`}</code></pre>
|
||||
|
||||
<p>
|
||||
O verbo é um <code>GET</code> e a URI é <code>/livros</code>. Isto significa que queremos <em>ler</em> o recurso chamado <em>livros</em>. Uma requisição para este endpoint deveria, portanto, ser respondida com uma lista
|
||||
de livros disponíveis.
|
||||
</p>
|
||||
|
||||
<pre><code>{`Request:
|
||||
GET /livros
|
||||
---
|
||||
Response:
|
||||
200 Ok
|
||||
|
||||
Andrew S. Tanembaum - Distributed Systems 4th Edition
|
||||
Thomas H. Cormen - Introduction to Algorithms
|
||||
Donald Knuth - The Art of Computer Programming`}</code></pre>
|
||||
</section>
|
||||
|
||||
<p>
|
||||
E se desejássemos obter um único livro, identificado pelo seu ISBN. Poderíamos fazer um endpoint:
|
||||
</p>
|
||||
|
||||
<pre><code>{`Request:
|
||||
GET /livros/9788574481371
|
||||
---
|
||||
Response:
|
||||
200 Ok
|
||||
Yasunari Kawabata - Contos da Palma da Mão`}</code></pre>
|
||||
|
||||
<p>
|
||||
Note que agora a URI ficou <code>/livros/<b>9788574481371</b></code> onde <code><b>9788574481371</b></code> é o ISBN do livro, é um dado que o identifica e pode ser uma chave primária.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
E como poderíamos representar o <em>estado de um recurso</em>? Podemos utilizar formatos específicos de dados,
|
||||
como o <a href="https://developer.mozilla.org/pt-BR/docs/Glossary/XML" target="_blank">XML</a>:
|
||||
</p>
|
||||
|
||||
<pre><code>{`Request:
|
||||
GET /livros/9788574481371
|
||||
---
|
||||
Response:
|
||||
200 OK
|
||||
|
||||
<livro>
|
||||
<isbn>9788574481371</isbn>
|
||||
<titulo>Contos da Palma da Mão</titulo>
|
||||
<autor>Yasunari Kawabata</autor>
|
||||
</livro>`}</code></pre>
|
||||
|
||||
<p>
|
||||
Ou o <a href="https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/JSON" target="_blank">JSON</a>, que é o mais comumente utilizado hoje em dia:
|
||||
</p>
|
||||
|
||||
<pre><code>{`Request:
|
||||
GET /livros/9788574481371
|
||||
|
||||
Response:
|
||||
200 Ok
|
||||
{
|
||||
"isbn": "9788574481371",
|
||||
"titulo": "Contos da Palma da Mão",
|
||||
"autor": "Yasunari Kawabata"
|
||||
}`}</code></pre>
|
||||
</section>
|
||||
@ -13,7 +13,7 @@
|
||||
Imagine que você foi escolhido para desenvolver um sistema de informação para a <b>biblioteca</b> da sua faculdade. Os usuários deste sistema serão
|
||||
os funcionários que o utilizarão para gerenciar a biblioteca. Os usuários devem ser capazes de <b>visualizar</b>, <b>cadastrar</b>, <b>editar</b>
|
||||
e <b>remover</b> os <b>livros</b> que estão disponíveis, além
|
||||
de registrar quando um livro foi <b>emprestado</b> para um <b>aluno</b>. Para isso, vamos desenvolver uma API que irá expor <em>endpoints</em> para cada uma destas operações:
|
||||
de registrar quando um livro foi <b>emprestado</b> para um <b>aluno</b>. Para isso, vamos desenvolver uma <em>API REST</em> que irá expor <em>endpoints</em> para cada uma destas operações:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user