Enable javascript in your browser for better experience. Need to know to enable it? Go here.
As informações desta página não estão completamente disponíveis no seu idioma de escolha. Esperamos disponibiliza-las integralmente em outros idiomas em breve. Para ter acesso às informações no idioma de sua preferência, faça o download do PDF aquí.
Atualizado em : Mar 29, 2017
NÃO ENTROU NA EDIÇÃO ATUAL
Este blip não está na edição atual do Radar. Se esteve em uma das últimas edições, é provável que ainda seja relevante. Se o blip for mais antigo, pode não ser mais relevante e nossa avaliação pode ser diferente hoje. Infelizmente, não conseguimos revisar continuamente todos os blips de edições anteriores do Radar. Saiba mais
Mar 2017
Hold ? Prossiga com cautela.

With the increasing popularity of the BFF - Backend for frontends pattern and use of one-way data-binding frameworks like React.js, we've noticed a backlash against REST-style architectures. Critics accuse REST of causing chatty, inefficient interactions among systems and failing to adapt as client needs evolve. They offer frameworks such as GraphQL or Falcor as alternative data-fetch mechanisms that let the client specify the format of the data returned. But in our experience, it isn't REST that causes these problems. Rather, they stem from a failure to properly model the domain as a set of resources. Naively developing services that simply expose static, hierarchical data models via templated URLs result in an anemic REST implementation. In a richly modeled domain, REST should enable more than simple repetitive data fetching. In a fully evolved RESTful architecture, business events and abstract concepts are also modeled as resources, and the implementation should make effective use of hypertext, link relations and media types to maximize decoupling between services. This antipattern is closely related to the Anemic Domain Model pattern and results in services that rank low in Richardson Maturity Model. We have more advice for designing effective REST APIs in our Insights article

.

Nov 2016
Hold ? Prossiga com cautela.

With the increasing popularity of the BFF - Backend for frontends pattern and use of one-way data-binding frameworks like React.js, we’ve noticed a backlash against REST-style architectures. Critics accuse REST of causing chatty, inefficient interactions among systems and failing to adapt as client needs evolve. They offer frameworks such as GraphQL or Falcor as alternative data-fetch mechanisms that let the client specify the format of the data returned. But in our experience, it isn’t REST that causes these problems. Rather, they stem from a failure to properly model the domain as a set of resources. Naively developing services that simply expose static, hierarchical data models via templated URLs result in an anemic REST implementation. In a richly modeled domain, REST should enable more than simple repetitive data fetching. In a fully evolved RESTful architecture, business events and abstract concepts are also modeled as resources, and the implementation should make effective use of hypertext, link relations and media types to maximize decoupling between services. This antipattern is closely related to the Anemic Domain Model pattern and results in services that rank low in Richardson Maturity Model. We have more advice for designing effective REST APIs in our Insights article.

Publicado : Nov 07, 2016

Baixe o PDF

 

 

 

English | Español | Português | 中文

Inscreva-se para receber o boletim informativo Technology Radar

 

 

Seja assinante

 

 

Visite nosso arquivo para acessar os volumes anteriores