book

Livro de receitas de padrões e práticas de API da Web RESTful

by Mike Amundsen

April 2025

Intermediate to advanced

470 pages

12h 33m

Portuguese (Portugal, Brazil)

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Sobre este livroConvenções utilizadas neste livroUtilizar exemplos de códigoAprendizagem em linha da O'ReillyComo contactar-nosAgradecimentos
O que são APIs da Web RESTful?Porquê a hipermédia?Princípios partilhados para serviços escaláveis na Web
Estabelecer uma base com concepções hipermédiaAumentar a resiliência com clientes de hipermédiaPromover a estabilidade e a modificabilidade comserviços hipermédiaSuporte a dados distribuídosPotenciar a extensibilidade com o fluxo de trabalho hipermédia
3.1. Criação de interoperabilidade com tipos de meios registados3.2. Assegurar a compatibilidade futura comtipos de suportes estruturados3.3. Partilha de especificidades de domínio através de vocabulários publicados3.4. Descrever espaços problemáticos com perfis semânticos3.5. Exprimir acções em tempo de execução com hipermédia incorporada3.6. Conceber escritas de dados consistentes comacções idempotentes3.7. Permitir a interoperabilidade comtransferências de estado entre serviços3.8. Conceber acções repetíveis3.9. Conceber para acções reversíveis3.10. Conceber mensagens extensíveis3.11. Conceber interfaces modificáveis
4.1. Limitar o uso de URLs codificadas4.2. Codificando Clientes para serem conscientes do HTTP4.3. Codificando Clientes Resilientes com Implementações Centradas em Mensagens4.4. Codificação de Clientes Eficazes para CompreenderPerfis de Vocabulário4.5. Negociando o suporte a perfis em tempo de execução4.6. Gerir os formatos de representação em tempo de execução4.7. Utilização de documentos de esquema como fonte demetadados de mensagens4.8. Cada elemento importante de uma respostaprecisa de um identificador4.9. Confiar nos controlos hipermédia da resposta4.10. Ligações de apoio e formulários paraserviços não hipermédia4.11. Validando propriedades de dados em tempo de execução4.12. Utilizar esquemas de documentos para validarmensagens de saída4.13. Utilização de consultas de documentos para validarmensagens recebidas4.14. Validação dos dados recebidos4.15. Atualizar o teu próprio estado4.16. Ter um objetivo em mente
5.1. Publicar pelo menos um URL estável5.2. Prevenir fugas de modelos internos5.3. Conversão de modelos internos em mensagens externas5.4. Expressar funções internas como acções externas5.5. Apoio publicitário às preferências de resposta dos clientes5.6. Suporte à negociação de conteúdo HTTP5.7. Publicar vocabulários completos para clientes de máquinas5.8. Apoiar vocabulários partilhados em formatos normalizados5.9. Publicação de documentos de definição de serviços5.10. Publicar metadados da API5.11. Apoio à monitorização do estado do serviço5.12. Normalização do relatório de erros5.13. Melhorar a capacidade de descoberta de serviços com um registo de serviços em tempo de execução5.14. Aumentando a taxa de transferência com identificadores fornecidos pelo cliente5.15. Melhorar a fiabilidade com Idempotent Criar5.16. Fornecimento de fallbacks em tempo de execução para serviços dependentes5.17. Utilizar proxies semânticos para aceder aserviços não conformes
6.1. Escondendo os componentes internos do teu armazenamento de dados6.2. Tornar todas as alterações idempotentes6.3. Ocultar relações de dados para acções externas6.4. Aproveitamento de URLs HTTP para suportar consultas "Contém" e "E" consultas6.5. Devolver metadados para respostas a consultas6.6. Retorno de HTTP 200 versus HTTP 400 paraconsultas centradas em dados6.7. Usando tipos de mídia para consultas de dados6.8. Ignorar campos de dados desconhecidos6.9. Melhorar o desempenho com diretivas de cache6.10. Modificação de modelos de dados na produção6.11. Extensão de armazenamentos de dados remotos6.12. Limitação das respostas em grande escala6.13. Usando proxies de passagem para troca de dados

7.1. Conceber serviços compatíveis com o fluxo de trabalho7.2. Suporte ao estado partilhado para fluxos de trabalho7.3. Descreve o fluxo de trabalho como código7.4. Descreve o fluxo de trabalho como DSL7.5. Descreve o fluxo de trabalho como documentos7.6. Suporte da linguagem de controlo de trabalhos RESTful7.7. Expor um recurso de progresso para os teus fluxos de trabalho7.8. Devolver todas as acções relacionadas7.9. Devolver os recursos utilizados mais recentemente7.10. Apoiar o trabalho em curso com estado7.11. Ativar a navegação na lista padrão7.12. Formulário parcial de apoio Enviar7.13. Usando o State-Watch para habilitar o fluxo de trabalho orientado ao cliente7.14. Otimização de consultas com repetições armazenadas7.15. Resposta síncrona para trabalho incompletocom 202 aceite7.16. Correcções de curto prazo com tentativas automáticas7.17. Apoiar a anulação ou reversão local7.18. Pedir ajuda7.19. Dimensionando o fluxo de trabalho com filas e clusters7.20. Usando Proxies de Fluxo de Trabalho para AlistarServiços Não-Conformes
Aplicar estas receitasTransformar os serviços existentesRecursos adicionaisPróximos passos
Tipos de meios de comunicação registados viáveis para APIs Web RESTfulFormatos de definição de APIFormatos de documentos de perfil semânticoTipos de suporte de hipermédia
Olá, Hiper!Outras informações

Content preview from Livro de receitas de padrões e práticas de API da Web RESTful

Capítulo 4. Clientes hipermédia

Este trabalho foi traduzido com recurso a IA. Agradecemos o teu feedback e comentários: translation-feedback@oreilly.com

A boa notícia sobre os computadores é que eles fazem o que tu lhes dizes para fazer. A má notícia é que eles fazem o que tu lhes dizes para fazer.

Ted Nelson

Escrever aplicativos que usam APIs para consumir serviços externos na Web requer uma mistura de especificidade(o que fazer) e generalidade(como fazer) que pode ser desafiadora. As receitas neste capítulo estão focadas no que dizemos às aplicações cliente para fazer usando código local e como dizemos a elas por meio do protocolo e das mensagens que enviamos para frente e para trás. Esta combinação de "o quê" e "como" constitui a base de aplicações de consumo de API estáveis, mas flexíveis.

Dica

Para obter mais informações sobre a arte de criar consumidores de API, consulta "Aumentar a resiliência com clientes de hipermédia".

Como regra geral, ser muito explícito sobre o que os clientes podem e não podem fazer resultará em aplicações que são fáceis de quebrar e difíceis de reutilizar. Uma abordagem melhor é criar aplicativos de consumo de API que fazem apenas algumas afirmações básicas sobre como eles se comunicam (por exemplo, protocolo, modelo de mensagem e vocabulário) com servidores e deixam o servidor fornecer todos os outros detalhes (o quê) em tempo de execução. Como mostra a Figura 4-1, as receitas deste capítulo concentram-se na utilização de formatos hipermédia ...