Restful considerada prejudicial parte 2

1. RESTful considerada
prejudicial – Parte 2
Misturando códigos de status HTTP
com Respostas Negócios
sinalização idiomaticamente erros de negócios através resto deve
usar 4xx classe de códigos de status. No entanto, estes erros não
foram projetados para sinalizar casos de negócios, então eu
constantemente encontrar-me a tentar mapear os códigos 4xx
aos resultados de negócios. Teste CAPTCHA falhou? Vamos
torná-lo 400 Bad pedido. erro de validação de formulário? 417
Expectation falhado? violação de restrição devido à duplicação?
409 Conflito? Mas o que sobre a exceção de bloqueio otimista? O
que se o cliente tem saldo insuficiente? E se ... Esses códigos de
erro são projetados para recuperação de documentos, não é rico
de negócios por trás back-end. Você acaba com colocar tudo sob
o mesmo código de status ou a construção de complexo
documento tradução. Nós inventamos exceções, falhas, Either<T> -
apenas para limitar-nos de repente conjunto fixo de códigos de
erro numéricos.
404 é especialmente problemático, porque é tão prevalente. Ao
usar API RESTful você nunca pode dizer se 404 é uma
circunstância de negócios ou apenas um erro de digitação na
URL. Soa como uma receita para o inferno depuração distribuído.
Ah, e eu mencionei há nenhuma maneira padrão de codificação
de erros?
Acoplamento temporal
APIs RESTful são muito populares entre os fanboys Microservice.
Mas vamos voltar ao básico. APIs RESTful são baseados em
HTTP, que é um protocolo de solicitação-resposta construída em
cima de TCP / IP. TCP / IP cria uma abstração de conexão no
topo do protocolo IP orientada para o pacote. IP é apenas capaz
de entregar mensagens de uma máquina para outra. Através da
construção de todos esses níveis de abstrações que se esqueceu

2. de que web é realmente assíncrona. Acreditamos que, usando
JSON frouxa contrato-menos não somos mais acoplar sistemas
juntos. Mas há uma outra dimensão do acoplamento: a
dependência temporal. Se um sistema precisa notificar outra
sobre algum evento, será que eles realmente precisam existir ao
mesmo tempo. Em alguns casos, normalmente implementado
com GET, solicitação-resposta faz sentido. Mas na maioria dos
casos o que realmente queremos é um fogo-e-esqueça, em
situação de menos uma vez a semântica. arquiteturas
distribuídas controlados por mensagem provou ser muito mais
robusto e tolerante a falhas. Dois sistemas já não precisam de ver
uns aos outros e viver ao mesmo tempo. Além disso, um sistema
deixará de quebrar outro se ele está produzindo muitas
solicitações. Basta colocar uma fila persistente entre dois
sistemas. Esta abordagem tem várias vantagens:
• produtores e consumidores pode ser reiniciado a qualquer
momento sem perda de dados ou a qualidade do serviço
degradado
• escalabilidade é mais fácil de conseguir, não há necessidade de
balanceamento de carga complexa
• podemos enviar mensagens para múltiplos sistemas de uma só
vez
• depuração pode ser mais fácil com padrão tap fio
RESTful também não tem noção de pedidos de sentido único.
POST sem corpo é tão perto quanto você pode obter. Isso é
problemático, porque muitos casos de negócios são naturalmente
ajustando o fogo-e-esqueça semântica. Quando estou publicando
eventos de domínio Eu não me importo sobre a resposta, mas os
serviços REST são muito intimamente ligado com o protocolo
HTTP.
Somente interações de solicitação-resposta típico (como a
recuperação de um usuário por ID) não são um bom ajuste para
as filas embora. filas temporais com IDs de correlação são
desajeitados e introduzir uma grande quantidade de latência.

3. Sem padrões
Não existem normas, mas apenas boas práticas, por vezes,
contraditórias. Nós não podemos até concordar se os recursos
devem estar no singular ou no plural, para não mencionar
parâmetros de paginação, tratamento de erros, HATEOAS ...
Você vai encontrar pessoas discutindo como RESTful é o seu
serviço, de acordo com Richardson Modelo de Maturidade. Falta
de normas significa que todo mundo pode nomear seu serviço
RESTful. Pode ser um exemplo vivo de dissertação de Roy
Fielding, que poderia ser um <form> manipulador POST - contanto
que eles usam HTTP, eles são REST. Isto também significa que
você nunca agora como interagir adequadamente com qualquer
API. Que cabeçalhos você deve usar, como decodificar a
resposta, como o conteúdo tipo é negociado (cabeçalhos?
Extensão no URL?) E quais tipos são suportados.
Compatibilidade com versões
anteriores
serviços RESTful têm poucas formas imperfeitas de manipulação
de compatibilidade com versões anteriores:
• única adição de campos, não remover ou alterar. Eu
testemunhei uma situação onde alguém fixa um erro de digitação
inocente em um objeto que passou a ser codificado diretamente
como JSON. Este caiu outro sistema
• Tipo de conteúdo com controle de versão - dolorosa e requer a
manutenção de várias versões
• HTTP redireciona se os recursos são renomeados - só funciona
se os clientes são RESTful suficiente, evitando URLs codificadas
inteiramente
Cada técnica acima tem seus próprios problemas, serviços
RESTful simplesmente não são projetados para ser em evolução.
Alternativas

4. Algumas perguntas que eu quero que você pergunte a si mesmo
antes de saltar para JSON sobre HTTP RESTO hippie-estilo
a.k.a. da integração:
• é o desempenho é uma preocupação? Em seguida, escolher o
formato mais compacto que não requer compressão caro
• Você realmente precisa de bloqueio de solicitação-resposta? Se
não, considere fila de mensagens ou loja, como Kafka
• está fazendo a implantação contínua ou auto-scaling? Em
seguida, escolher a tecnologia que faz cliente não par eo servidor
temporariamente e é sem conexão, veja acima
• são as suas interacções complexas ou talvez você está
extraindo API existente / interface a partir do módulo de serviço
distribuído? Em seguida, escolher a tecnologia mais perto de
RPC clássico
• você precisa semântica exatamente-uma vez? Se assim for,
nada vai ajudá-lo, desculpe.