jeffotoni/api-rest.txt

## api-rest.txt


Mafê
Jefferson Otoni (via zoom) e Raphael Rossi (presencial)

zoom
https://us02web.zoom.us/j/89048168371


Princípio:
API é um conjunto de definições e protocolos usado no desenvolvimento e na integração de software de aplicações.

API (Application Programming Interface) é um acrônimo em inglês.

Conceito:
O conceito de API nada mais é do que uma forma de comunicação entre sistemas.
Elas permitem a integração entre dois sistemas, em que um deles fornece
informações e serviços que podem ser utilizados pelo outro, sem a necessidade
do sistema que consome a API conhecer detalhes de implementação do software.

Tipos de Web Services:
REST
SOAP
XML-RPC

Concepções rEST
Resources 	      = /insert, /update , /search [URI]
Representation   = Html, Json, Xml, ... / Content-Type
State Transfer     = GET, POST, PUT ...

Gravação 2 - API - Princípios, conceitos e como criar

O que seria APIs?

Poderia citar alguns tipos de Web Service?

E o protocolo HTTP tem como desmistificar um pouco ele?

RESTful vs REST (Representational State Transfer) o que seria?

O que são APIs poliglotas?

O que são API management e API-GATEWAY ou é tudo igual?

Existe algum órgão para regulamentar a criação de APIs Web?

Como acredita que será a evolução quando o assunto é API Web?

Como é a rotina de vocês na Engineering?

No geral, como enxerga o mercado de tecnologia atualmente?


história API-GATEWAY

KONG -> 2009 A 2011 A 2015 OPEN SOURCE
API-GATEWAY AWS -> July 9, 2015
API-GATEWAY GOOGLE -> 20
sensedia -> 2012

2015-> o gRPC no ano de 2015 porque buscava uma solução mais completa e robusta para conectar os microsserviços

MICROSERVICES EMERGINDO EM 2011
Em 1978 McIlroy, Pinsen e Tague publicaram artigo com o contexto de situações mais flexíveis e em escalas diversas, que pode ser pensado como base para este formato de arquitetura.

RPC (Chamada de procedimento remoto)

HISTORIA
[https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Overview]

A origem do HTTP

O HTTP é um protocolo extensível
é sem estado, mas tem sessões cookies HTTP permitem que as sessões tenham estados.

http/0.9 -> 1991  (abrir uma conexão requer várias viagens de ida/volta de mensagens)
http/1.0 -> 1996  (uma conexão TCP era aberta para cada par de requisição/resposta trocada)
http/1.1 -> 1999  (pipelining)

HTTP/2.0 -> 2015 ( tcp/SPDY ) multiplexando várias mensagens através de uma única conexão (conexão mais quente, e mais eficiente)
HTTP/3.0 -> 2019 ( upd/QUIC )

O HTTP surgiu dos esforços coordenados pelo World Wide Web Consortium, que culminaram na publicação de artigos sobre o protocolo com um pedido para que a comunidade internacional avaliasse se ele poderia se tornar um padrão em todo o mundo.
Assim nasceu, em 1999, o HTTP/1.1, para suprir a necessidade de distribuir de forma padronizada informações que vão além de simples textos, entre clientes e servidores, por todos os computadores ligados à internet.


Projetado no início da década de 1990, o protocolo HTTP é extensível e evoluiu ao longo do tempo. Atua na camada de aplicação e é enviado sobre o protocoloTCP, ou em uma conexão TCP criptografada com TLS, embora qualquer protocolo de transporte confiável possa, teoricamente, ser usado. Devido à sua extensibilidade, ele é usado não só para buscar documentos de hipertexto, mas também imagens e vídeos ou publicar conteúdo em servidores, como nos resultados de formulário HTML (veja os elementos <html> e <form>). O HTTP também pode ser usado para buscar partes de documentos para atualizar páginas da Web sob demanda.


[https://go-talks.appspot.com/github.com/gobelohorizonte/gotalks/server-rest.slide#26]

2015 foi lançado o HTTP/2
[https://developers.google.com/web/fundamentals/performance/http2#:~:text=The%20primary%20goals%20for%20HTTP,request%20prioritization%20and%20server%20push.&text=HTTP%2F2%20does%20not%20modify,of%20HTTP%20in%20any%20way.]

- Março de 2012: Chamada para propostas de HTTP/2
- Novembro de 2012: Primeiro rascunho do HTTP/2 (baseado no SPDY)
- Agosto de 2014: Publicação do rascunho 17 do HTTP/2 e do rascunho 12 do HPACK
- Agosto de 2014: Última chamada do Grupo de Trabalho para o HTTP/2
- Fevereiro de 2015: IESG aprova os rascunho do HTTP/2 e do HPACK
- Maio de 2015: O RFC 7540 (HTTP/2) e o RFC 7541 (HPACK) são publicados

[https://hpbn.co/http2/]


[https://www.redhat.com/pt-br/topics/api/what-are-application-programming-interfaces]
Um breve histórico das APIs
As APIs surgiram nos primeiros dias da computação, muito antes do computador pessoal. Naquela época, elas eram normalmente usadas como bibliotecas para sistemas operacionais. Embora a API enviasse mensagens entre mainframes em alguns momentos, ela era quase sempre local para os sistemas em que operava. Depois de quase 30 anos, as APIs se expandiram para além dos ambientes locais. No início dos anos 2000, elas estavam se tornando uma tecnologia importante para a integração remota de dados.


Openapis
https://spec.openapis.org/oas/v3.1.0
https://github.com/OAI/OpenAPI-Specification

Lançamento 10 de agosto de 2011

A OpenAPI Initiative (OAI) foi criada por um consórcio de especialistas da indústria voltados
para o futuro que reconhecem o imenso valor da padronização sobre como as APIs são descritas.


As vantagens de utilizar o OpenAPI Spec
são basicamente as mesmas de usar RAML Spec,
Swagger Spec, ou API Blueprint Spec: Modelar e documentar APIs REST.

Em janeiro de 2016, a SmartBear Software renomeou a Swagger Specification para OpenAPI Specification.


A Iniciativa OpenAPI é um projeto de colaboração de código aberto da Linux Foundation. Foi criado por um consórcio de especialistas da indústria voltados para o futuro que reconhecem o valor de padronizar como as APIs são descritas.

Como uma estrutura de governança aberta sob a Linux Foundation,
a OAI está focada na criação, evolução e promoção de um formato de descrição neutro do fornecedor.
A especificação OpenAPI foi originalmente baseada na especificação Swagger, doada pela SmartBear Software.

A especificação OpenAPI (OAS) define
uma descrição de interface agnóstica de linguagem de programação padrão para APIs REST,
que permite que humanos e computadores descubram e entendam os recursos de um serviço
sem exigir acesso ao código-fonte, documentação adicional ou inspeção do tráfego de rede .

Quando definido corretamente por meio do OpenAPI, um consumidor pode entender
e interagir com o serviço remoto com uma quantidade mínima de lógica de implementação.
Semelhante ao que as descrições de interface fizeram para a programação
de nível inferior, a especificação OpenAPI remove as suposições ao chamar um serviço.


----- microserivces
O uso de APIs RESTful permite – e até estimula – a entrega mais rápida
de novos recursos e atualizações. Cada serviço é independente.
Um serviço pode ser substituído, aprimorado ou descartado sem afetar nenhum outro na arquitetura.
Com essa arquitetura leve, é possível otimizar os serviços distribuídos ou de cloud
e oferecer suporte à escalabilidade dinâmica para serviços individuais.

APIs remotas
As APIs remotas foram projetadas para interagir por meio de uma rede de comunicações. Quando falamos “remota”, queremos dizer que os recursos manipulados pela API estão em algum lugar fora do computador que faz a solicitação. Como a rede de comunicações mais usada é a Internet, a maioria das APIs são projetadas com base em padrões da web. Nem todas as APIs remotas são web, mas é justo afirmar que, em geral, as APIs web são remotas.


As APIs web normalmente usam o protocolo HTTP para mensagens de solicitação e fornecem uma definição da estrutura das mensagens de resposta. Essas mensagens de resposta geralmente têm o formato de arquivo XML ou JSON. Tanto XML quanto JSON são formatos de preferência porque apresentam os dados de forma simplificada, o que facilita a manipulação por outras aplicações.


consideradas RESTful se estiverem em conformidade com seis restrições de arquitetura:
 - Arquitetura cliente-servidor
 - Sem monitoração de estado
 - Capacidade de cache
 - Sistema em camadas
 - Código sob demanda (opcional):
 - Interface uniforme


[https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm]

Oficialmente o termo API RESTful apareceu pela primeira vez na
tese de doutorado de "Roy Fieldings" chamada de
“Architectural Styles and the Design of Network-based Software Architectures“,
publicada em 2000 pela Universidade da Califórnia.
Ali foram descritos os primeiros conceitos sobre APIRESTful e muitos são utilizados até hoje.


PINHONEIROS
Salesforce e o primeiro caso real de sucesso
Porém, na prática, o nascimento da API foi durante o evento IDG Demo 2000, quando o Salesforce, software de CRM, lançou sua primeira API em 7 de Fevereiro de 2000 feita em XML.

eBay Developer Program
Pouco mais tarde, em 20 de Novembro de 2000, o eBay lançou sua API. Com o famoso “eBayDeveloper Program”, trouxeram a tecnologia das APIs para o segmento de e-commerce, revolucionando todo o mercado.

Amazon Web Services
Um pouco depois, em 16 de Julho de 2002, a Amazon também lançou sua API que permitiu a outros desenvolvedores adicionarem conteúdo e funcionalidades da Amazon em seus próprios sites.


Em Agosto de 2004, seis meses após o lançamento da plataforma,
a API do Flickr era liberada.
O lançamento da sua API fez com que o Flickr crescesse rapidamente, consolidando a empresa como a plataforma preferida pelos blogueiros da época. Esse ritmo de crescimento acelerado abriu os olhos do mercado para o que estava acontecendo e, menos de um ano pós o lançamento da API, o Flickr foi adquirido pelo Yahoo por algo em torno de 25 milhões de dólares.


Amazon S3 e a revolução na infraestrutura das empresas
Em março de 2006 algo aconteceu. A Amazon apresentava ao mundo sua API focada no armazenamento de dados, o Amazon S3 e, seis meses depois lançou o Amazon EC2, permitindo que toda a infraestrutura de uma empresa de tecnologia pudesse ser criada via API.


Tipos de Web Services / http/https {json/xml}
REST / Framework Mux
SOAP / framework {wsdl2Go , Soaptrip}
XML-RPC / XmlRpc

REST (Representational State Transfer)

Concepções Rest
Resources = /insert, /update , /search [URI]
Representation = Html, Json, Xml, ... / Content-Type
State Transfer = GET, POST, PUT ...


O que é REST API? (estilo arquitetônico de serviço web)
Antes de irmos direto ao assunto, vamos primeiro entender o que é REST. Ao contrário da crença de muitos, REST não é um protocolo, uma ferramenta ou biblioteca,
mas sim um estilo arquitetônico de serviço web que fornece um canal de comunicação entre sistemas ou computadores na internet. É um padrão utilizado como meio de arquitetura para projetar um sistema de software baseado em rede.

Portanto, uma API REST é uma interface de programa de aplicativo que é apoiada pelo estilo arquitetônico de REST. Refere-se a ferramentas, serviço ou software que se baseia no princípio de arquitetura REST. Embora REST possa ser usado em quase qualquer protocolo, eles aproveitam o HTTP quando usados para APIs da web.
A principal vantagem das APIs REST é que elas oferecem mais flexibilidade.
Em APIs REST, os dados não são restritos a recursos ou métodos. Portanto, ele pode fazer vários tipos de chamadas, retornar vários formatos de dados e até mesmo mudar estruturalmente com a implementação adequada de hipermídia.



	Mafê
	Jefferson Otoni (via zoom) e Raphael Rossi (presencial)

	zoom
	https://us02web.zoom.us/j/89048168371


	Princípio:
	API é um conjunto de definições e protocolos usado no desenvolvimento e na integração de software de aplicações.

	API (Application Programming Interface) é um acrônimo em inglês.

	Conceito:
	O conceito de API nada mais é do que uma forma de comunicação entre sistemas.
	Elas permitem a integração entre dois sistemas, em que um deles fornece
	informações e serviços que podem ser utilizados pelo outro, sem a necessidade
	do sistema que consome a API conhecer detalhes de implementação do software.

	Tipos de Web Services:
	REST
	SOAP
	XML-RPC

	Concepções rEST
	Resources = /insert, /update , /search [URI]
	Representation = Html, Json, Xml, ... / Content-Type
	State Transfer = GET, POST, PUT ...

	Gravação 2 - API - Princípios, conceitos e como criar

	O que seria APIs?

	Poderia citar alguns tipos de Web Service?

	E o protocolo HTTP tem como desmistificar um pouco ele?

	RESTful vs REST (Representational State Transfer) o que seria?

	O que são APIs poliglotas?

	O que são API management e API-GATEWAY ou é tudo igual?

	Existe algum órgão para regulamentar a criação de APIs Web?

	Como acredita que será a evolução quando o assunto é API Web?

	Como é a rotina de vocês na Engineering?

	No geral, como enxerga o mercado de tecnologia atualmente?


	história API-GATEWAY

	KONG -> 2009 A 2011 A 2015 OPEN SOURCE
	API-GATEWAY AWS -> July 9, 2015
	API-GATEWAY GOOGLE -> 20
	sensedia -> 2012

	2015-> o gRPC no ano de 2015 porque buscava uma solução mais completa e robusta para conectar os microsserviços

	MICROSERVICES EMERGINDO EM 2011
	Em 1978 McIlroy, Pinsen e Tague publicaram artigo com o contexto de situações mais flexíveis e em escalas diversas, que pode ser pensado como base para este formato de arquitetura.

	RPC (Chamada de procedimento remoto)

	HISTORIA
	[https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Overview]

	A origem do HTTP

	O HTTP é um protocolo extensível
	é sem estado, mas tem sessões cookies HTTP permitem que as sessões tenham estados.

	http/0.9 -> 1991 (abrir uma conexão requer várias viagens de ida/volta de mensagens)
	http/1.0 -> 1996 (uma conexão TCP era aberta para cada par de requisição/resposta trocada)
	http/1.1 -> 1999 (pipelining)

	HTTP/2.0 -> 2015 ( tcp/SPDY ) multiplexando várias mensagens através de uma única conexão (conexão mais quente, e mais eficiente)
	HTTP/3.0 -> 2019 ( upd/QUIC )

	O HTTP surgiu dos esforços coordenados pelo World Wide Web Consortium, que culminaram na publicação de artigos sobre o protocolo com um pedido para que a comunidade internacional avaliasse se ele poderia se tornar um padrão em todo o mundo.
	Assim nasceu, em 1999, o HTTP/1.1, para suprir a necessidade de distribuir de forma padronizada informações que vão além de simples textos, entre clientes e servidores, por todos os computadores ligados à internet.


	Projetado no início da década de 1990, o protocolo HTTP é extensível e evoluiu ao longo do tempo. Atua na camada de aplicação e é enviado sobre o protocoloTCP, ou em uma conexão TCP criptografada com TLS, embora qualquer protocolo de transporte confiável possa, teoricamente, ser usado. Devido à sua extensibilidade, ele é usado não só para buscar documentos de hipertexto, mas também imagens e vídeos ou publicar conteúdo em servidores, como nos resultados de formulário HTML (veja os elementos <html> e <form>). O HTTP também pode ser usado para buscar partes de documentos para atualizar páginas da Web sob demanda.


	[https://go-talks.appspot.com/github.com/gobelohorizonte/gotalks/server-rest.slide#26]

	2015 foi lançado o HTTP/2
	[https://developers.google.com/web/fundamentals/performance/http2#:~:text=The%20primary%20goals%20for%20HTTP,request%20prioritization%20and%20server%20push.&text=HTTP%2F2%20does%20not%20modify,of%20HTTP%20in%20any%20way.]

	- Março de 2012: Chamada para propostas de HTTP/2
	- Novembro de 2012: Primeiro rascunho do HTTP/2 (baseado no SPDY)
	- Agosto de 2014: Publicação do rascunho 17 do HTTP/2 e do rascunho 12 do HPACK
	- Agosto de 2014: Última chamada do Grupo de Trabalho para o HTTP/2
	- Fevereiro de 2015: IESG aprova os rascunho do HTTP/2 e do HPACK
	- Maio de 2015: O RFC 7540 (HTTP/2) e o RFC 7541 (HPACK) são publicados

	[https://hpbn.co/http2/]


	[https://www.redhat.com/pt-br/topics/api/what-are-application-programming-interfaces]
	Um breve histórico das APIs
	As APIs surgiram nos primeiros dias da computação, muito antes do computador pessoal. Naquela época, elas eram normalmente usadas como bibliotecas para sistemas operacionais. Embora a API enviasse mensagens entre mainframes em alguns momentos, ela era quase sempre local para os sistemas em que operava. Depois de quase 30 anos, as APIs se expandiram para além dos ambientes locais. No início dos anos 2000, elas estavam se tornando uma tecnologia importante para a integração remota de dados.


	Openapis
	https://spec.openapis.org/oas/v3.1.0
	https://github.com/OAI/OpenAPI-Specification

	Lançamento 10 de agosto de 2011

	A OpenAPI Initiative (OAI) foi criada por um consórcio de especialistas da indústria voltados
	para o futuro que reconhecem o imenso valor da padronização sobre como as APIs são descritas.


	As vantagens de utilizar o OpenAPI Spec
	são basicamente as mesmas de usar RAML Spec,
	Swagger Spec, ou API Blueprint Spec: Modelar e documentar APIs REST.

	Em janeiro de 2016, a SmartBear Software renomeou a Swagger Specification para OpenAPI Specification.



	A Iniciativa OpenAPI é um projeto de colaboração de código aberto da Linux Foundation. Foi criado por um consórcio de especialistas da indústria voltados para o futuro que reconhecem o valor de padronizar como as APIs são descritas.

	Como uma estrutura de governança aberta sob a Linux Foundation,
	a OAI está focada na criação, evolução e promoção de um formato de descrição neutro do fornecedor.
	A especificação OpenAPI foi originalmente baseada na especificação Swagger, doada pela SmartBear Software.

	A especificação OpenAPI (OAS) define
	uma descrição de interface agnóstica de linguagem de programação padrão para APIs REST,
	que permite que humanos e computadores descubram e entendam os recursos de um serviço
	sem exigir acesso ao código-fonte, documentação adicional ou inspeção do tráfego de rede .

	Quando definido corretamente por meio do OpenAPI, um consumidor pode entender
	e interagir com o serviço remoto com uma quantidade mínima de lógica de implementação.
	Semelhante ao que as descrições de interface fizeram para a programação
	de nível inferior, a especificação OpenAPI remove as suposições ao chamar um serviço.


	----- microserivces
	O uso de APIs RESTful permite – e até estimula – a entrega mais rápida
	de novos recursos e atualizações. Cada serviço é independente.
	Um serviço pode ser substituído, aprimorado ou descartado sem afetar nenhum outro na arquitetura.
	Com essa arquitetura leve, é possível otimizar os serviços distribuídos ou de cloud
	e oferecer suporte à escalabilidade dinâmica para serviços individuais.

	APIs remotas
	As APIs remotas foram projetadas para interagir por meio de uma rede de comunicações. Quando falamos “remota”, queremos dizer que os recursos manipulados pela API estão em algum lugar fora do computador que faz a solicitação. Como a rede de comunicações mais usada é a Internet, a maioria das APIs são projetadas com base em padrões da web. Nem todas as APIs remotas são web, mas é justo afirmar que, em geral, as APIs web são remotas.


	As APIs web normalmente usam o protocolo HTTP para mensagens de solicitação e fornecem uma definição da estrutura das mensagens de resposta. Essas mensagens de resposta geralmente têm o formato de arquivo XML ou JSON. Tanto XML quanto JSON são formatos de preferência porque apresentam os dados de forma simplificada, o que facilita a manipulação por outras aplicações.


	consideradas RESTful se estiverem em conformidade com seis restrições de arquitetura:
	- Arquitetura cliente-servidor
	- Sem monitoração de estado
	- Capacidade de cache
	- Sistema em camadas
	- Código sob demanda (opcional):
	- Interface uniforme



	[https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm]

	Oficialmente o termo API RESTful apareceu pela primeira vez na
	tese de doutorado de "Roy Fieldings" chamada de
	“Architectural Styles and the Design of Network-based Software Architectures“,
	publicada em 2000 pela Universidade da Califórnia.
	Ali foram descritos os primeiros conceitos sobre APIRESTful e muitos são utilizados até hoje.


	PINHONEIROS
	Salesforce e o primeiro caso real de sucesso
	Porém, na prática, o nascimento da API foi durante o evento IDG Demo 2000, quando o Salesforce, software de CRM, lançou sua primeira API em 7 de Fevereiro de 2000 feita em XML.

	eBay Developer Program
	Pouco mais tarde, em 20 de Novembro de 2000, o eBay lançou sua API. Com o famoso “eBayDeveloper Program”, trouxeram a tecnologia das APIs para o segmento de e-commerce, revolucionando todo o mercado.

	Amazon Web Services
	Um pouco depois, em 16 de Julho de 2002, a Amazon também lançou sua API que permitiu a outros desenvolvedores adicionarem conteúdo e funcionalidades da Amazon em seus próprios sites.


	Em Agosto de 2004, seis meses após o lançamento da plataforma,
	a API do Flickr era liberada.
	O lançamento da sua API fez com que o Flickr crescesse rapidamente, consolidando a empresa como a plataforma preferida pelos blogueiros da época. Esse ritmo de crescimento acelerado abriu os olhos do mercado para o que estava acontecendo e, menos de um ano pós o lançamento da API, o Flickr foi adquirido pelo Yahoo por algo em torno de 25 milhões de dólares.


	Amazon S3 e a revolução na infraestrutura das empresas
	Em março de 2006 algo aconteceu. A Amazon apresentava ao mundo sua API focada no armazenamento de dados, o Amazon S3 e, seis meses depois lançou o Amazon EC2, permitindo que toda a infraestrutura de uma empresa de tecnologia pudesse ser criada via API.


	Tipos de Web Services / http/https {json/xml}
	REST / Framework Mux
	SOAP / framework {wsdl2Go , Soaptrip}
	XML-RPC / XmlRpc

	REST (Representational State Transfer)

	Concepções Rest
	Resources = /insert, /update , /search [URI]
	Representation = Html, Json, Xml, ... / Content-Type
	State Transfer = GET, POST, PUT ...



	O que é REST API? (estilo arquitetônico de serviço web)
	Antes de irmos direto ao assunto, vamos primeiro entender o que é REST. Ao contrário da crença de muitos, REST não é um protocolo, uma ferramenta ou biblioteca,
	mas sim um estilo arquitetônico de serviço web que fornece um canal de comunicação entre sistemas ou computadores na internet. É um padrão utilizado como meio de arquitetura para projetar um sistema de software baseado em rede.

	Portanto, uma API REST é uma interface de programa de aplicativo que é apoiada pelo estilo arquitetônico de REST. Refere-se a ferramentas, serviço ou software que se baseia no princípio de arquitetura REST. Embora REST possa ser usado em quase qualquer protocolo, eles aproveitam o HTTP quando usados para APIs da web.
	A principal vantagem das APIs REST é que elas oferecem mais flexibilidade.
	Em APIs REST, os dados não são restritos a recursos ou métodos. Portanto, ele pode fazer vários tipos de chamadas, retornar vários formatos de dados e até mesmo mudar estruturalmente com a implementação adequada de hipermídia.