• (31) 99973-2709
  • hugomoraismendes@gmail.com

Category Archive Web

Redirecionamento de URLs no htaccess

Existem várias formas de fazer o redirecionamento de páginas Web. Através do arquivo htaccess é possível  aproveitar o bom ranqueamento das páginas no Google com SEO.

É bem simples fazer esse procedimento.

Primeiro abra o arquivo .htaccess no servidor do seu site.

Agora coloque o código abaixo no final do arquivo e altere o /pagina1 para a url que está no Google e o /pagina2 que é a nova url de página, como resultado, o redirecionamento ocorrerá automaticamente.

<IfModule mod_rewrite.c>
    redirect 301 /pagina1 /pagina2
</IfModule>

Você pode também fazer o redirecionamento de um domínio para outro:

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-SSL} !on
RewriteCond %{HTTP_HOST} ^seudominio.com.br$ [OR]
RewriteCond %{HTTP_HOST} ^www.seudominio.com.br$
RewriteRule ^/?$ "https\:\/\/www.seudominio.com.br\/" [R=301,L]

Também pode-se fazer o redirecionamento coringa, onde se vai carregar todas as URL do site atual na nova URL.
Esse redirecionamento é usado para se aproveitar a indexação das URLs atuais:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^seudominio.com.br.br$ [OR]
RewriteCond %{HTTP_HOST} ^seudominio.com.br$
RewriteRule ^(.*)$ "https\:\/\/www.seudominio.com.br\/$1" [R=301,L]

 

API RESTful x Microsserviço

O estilo arquitetônico do REST foi introduzido pela primeira vez em 2000, projetado principalmente para funcionar bem com HTTP / 1.1. Seu princípio básico é definir recursos nomeados que podem ser manipulados usando um pequeno número de métodos. Os recursos e métodos são conhecidos como substantivos e verbos de APIs. Com o protocolo HTTP, os nomes dos recursos são mapeados naturalmente para URLs e os métodos são mapeados naturalmente para os métodos HTTP POST, GET, PUT, PATCH e DELETE.

Existem muitos artigos excelentes falando sobre os princípios e designs de microsserviços, e a API RESTful parece ser muito semelhante aos microsserviços. Contudo, Microsserviços é mais sobre arquitetura, enquanto a API RESTful se concentra mais em como expor microsserviços.

Não importa como você implementa microsserviços, um dos principais motivadores é a esperança de um tempo de comercialização mais rápido então um de seus principais objetivos de design é criar um sistemas desacoplados, independentes e pequenos (permitindo a entrega independente de valor comercial), cada um dos quais

  • é fácil de entender / modificar (porque são pequenos)
  • é o único lugar com lógica / regra de negócios
  • não expõe quaisquer detalhes de implementação, como banco de dados para garantir acoplamento frouxo; também implica que as APIs ou funções RESTful que implementam agregados dentro de um contexto limitado devem pertencer a um microsserviço porque estão fortemente acopladas em termos de compartilhamento de muito design e arquitetura de alto nível, ou seja, linguagem de programação e estruturas, estrutura de acesso ao banco de dados, etc. para reduzir a complexidade, pois você pode não querer manter um módulo ou contexto limitado (ou seja Serviço de mensagens) que usa diferentes tecnologias e pilhas de tecnologia
  • pode ser implantado separadamente sem afetar os outros, desde que as interfaces permaneçam as mesmas
  • mais alguns benefícios (como escala separadamente, escolha de linguagens de programação, etc.)
  • complexidade de desenvolvimento comercial para complexidade operacional enfadonha, mas difícil, ou seja, questões transversais, como descoberta de serviço, segurança serviço a serviço e origem a serviço, observabilidade (incluindo telemetria e rastreamento distribuído)

Não gosto da ideia de pensar em microsserviços em termos de linhas de código ou número de métodos, mas na prática um contexto limitado pode ser um ótimo candidato para microsserviços. Se a entrega de mudanças requer uma coordenação lenta e cara, a arquitetura precisa ser revisada porque não atinge os objetivos.

O isolamento ou tolerância a falhas é um dos objetivos mais importantes ao projetar um microsserviço. Se um sistema consiste em um conjunto de microsserviços bem isolados, uma falha em um dos microsserviços não afetará todo o sistema. Por exemplo, se um microsserviço (como serviço para membros) é um serviço principal do qual muitos outros microsserviços dependem, precisamos pensar em como projetá-los para garantir que a comunicação e a interação com o serviço principal sejam tolerantes a falhas. O contexto limitado pode ajudar, com isso quero dizer que cada microsserviço (como serviço de mensagens) tem sua própria definição do mesmo modelo (como membro) e os mantém / sincroniza internamente para usá-los sem invocar os microsserviços. O agente de mensagens também pode ser usado como um intermediário entre eles ao tentar chamar microsserviços para alterar seu estado,

Portanto, microsserviços tem mais a ver com estilo de arquitetura e design, e você pode implementar um microsserviço sem a API RESTful. No entanto, a API RESTful facilita a construção de microsserviços fracamente acoplados.

A API RESTful foi introduzida antes dos microsserviços. É um dos protocolos RPC . Uma das idéias principais é que cada objeto possui uma interface uniforme . Por exemplo, os objetos são identificados e manipulados por meio de um padrão . No mundo da ASP.NET Web API, os objetos são organizados por meio de atributos de controladores, ações e HttpVerbs.

Ao contrário da API da biblioteca (na forma de .dll), API RESTful (na prática, a API exposta por meio de terminais HTTP)

  • é verdadeiramente fracamente acoplado (contanto que as interfaces e sua semântica permaneçam iguais, a implementação da API no servidor pode mudar a qualquer momento, sem se preocupar em interromper seus consumidores e implantações do lado do consumidor)
  • é agnóstico de linguagem

Portanto, microsserviços e API RESTful resolvem problemas diferentes, mas funcionam juntos!