Enable javascript in your browser for better experience. Need to know to enable it? Go here.
La información en esta página no se encuentra completamente disponible en tu idioma de preferencia. Muy pronto esperamos tenerla completamente disponible en otros idiomas. Para obtener información en tu idioma de preferencia, por favor descarga el PDF aquí.
Última actualización : Mar 29, 2017
NO EN LA EDICIÓN ACTUAL
Este blip no está en la edición actual del Radar. Si ha aparecido en una de las últimas ediciones, es probable que siga siendo relevante. Si es más antiguo, es posible que ya no sea relevante y que nuestra valoración sea diferente hoy en día. Desgraciadamente, no tenemos el ancho de banda necesario para revisar continuamente los anuncios de ediciones anteriores del Radar. Entender más
Mar 2017
Hold ? Continuar con precaución

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 ? Continuar con precaución

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

Descarga el PDF

 

 

 

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

Suscríbete al boletín informativo de Technology Radar

 

 

 

 

Suscríbete ahora

Visita nuestro archivo para leer los volúmenes anteriores