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 5. Serviços hipermédia

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

A melhor arquitetura de software "sabe" o que muda com frequência e facilita isso.

Paul Clements,Arquitetura de Software na Prática (Pearson)

Um dos principais desafios na conceção e implementação de APIs para serviços é equilibrar a usabilidade com a capacidade de evolução. É importante que as API de serviços sejam claras e fáceis de compreender. Ao mesmo tempo, é fundamental que essas mesmas interfaces sejam definidas de forma a permitir modificações futuras. Por último, o valor das API de serviços está frequentemente ligado à sua fiabilidade ao longo do tempo. É bom poder definir uma API que resolva um problema imediato. Mas como esse problema varia ao longo do tempo, os parâmetros operacionais mudam e as necessidades e objetivos mudam com o tempo, essa API - idealmente - deve continuar a ser útil. Isso é pedir muito de um design de interface de serviço!

Dica

Consulta a secção "Promover a estabilidade e a modificabilidade comserviços hipermédia" para obteres mais informações sobre os fundamentos da criação de interfaces de serviços.

Como a citação de abertura do capítulo implica, saber o que muda frequentemente num design de software e tornar isso mais fácil é um objetivo digno. Isso é especialmente verdadeiro para APIs de serviço. A API é o contrato - a promessa que precisa ser mantida.

Um grande exemplo disto pode ser encontrado ...