rest - mvc - react login spring

REST(HATEOAS) y ReactJS

Question

Estoy interesado en utilizar el principio HATEOAS de REST para reducir la lógica comercial en una aplicación SPA. En un contexto específico de React, me gustaría saber si hay desafíos que hacen que esto no sea práctico y, de no ser así, ¿cuál es una buena estrategia a seguir?

Ejemplos conceptuales del uso de HATEOAS para eliminar la lógica comercial de la IU:

• Delegar acciones de cuenta bancaria válidas al servicio REST
• Delegar el control de acceso basado en roles en el servicio REST

Solo he encontrado un enlace que sugiere que React / Flux no es compatible con una estrategia de HATEOAS , y no hay discusión significativa en otra parte. ¿Realmente no es factible en una aplicación React / Flux? Esa publicación SO no recibió suficiente atención. ¿Alguien tiene un enfoque favorito o recomendado para lograr el éxito (con o sin Flux o Redux)?

Alguien dio un ejemplo bastante detallado de aprovechar HATEOAS en el contexto de Angular . Estoy buscando algo similar para React.

Personalmente, me estoy imaginando la etiqueta rel en hipermedia enlaces que controlan qué componentes JSX se representan ( condicional JSX ). ¿Es ingenuo para una aplicación React en el mundo real? ¿Tal vez los componentes Reaccionados condicionalmente son demasiado gruesos para ser usados ​​de esta manera?

Estoy asumiendo que los hipermedia enlaces son proporcionados por una implementación HAL , o de lo contrario se ajustan a la convención de alimentación ATOM ( RFC4287 ).

Answer 1

Antes de dar la vuelta a mi respuesta más probable incorrecta / irrelevante, solo quiero que sepan que acabo de leer lo que es HATEOAS. Esa advertencia allí, por lo que he leído brevemente, HATEOAS parece ser sobre todo la API que le indica cómo navegar a través de sí mismo al proporcionarle un enlace a los recursos que son relevantes para el recurso que acaba de solicitar.

Siendo ese el caso, no veo una razón por la que no pueda implementar llamadas url ajax dinámicas en sus acciones que alterarán el estado de la aplicación de su SPA (es decir, Redux) en función de lo que se le ha proporcionado, sin embargo, usted Todavía necesita tener algo para representar el estado de una manera visual para todas las partes de su aplicación. Aquí hay una representación cruda, semi-seudo y no muy bien pensada de lo que quiero decir basado libremente en el ejemplo de su cuenta bancaria:

// our component file
import React from ''react''
import { makeAWithdrawl } from ''./actions''
export default React.createClass({
handleClick: function(e) {
e.preventDefault()
makeAWithdrawl(this.props.account.withdraw.href)
},
render: function () {
<div className="account">
<p className="account_number">{this.props.account.accountNumber}</p>
<p className="balance">{this.props.account.balance}</p>
<p><a href={this.props.account.deposit.href}>Deposit</a></p>
{this.props.account.withdraw ? <p><a onClick={this.handleClick}>Withdraw</a></p> : ''''}
</div>
}
})
// our actions file
import store from ''store'' // our redux store
import axios from ''axios'' // an ajax library
export function makeAWithdrawl(url) {
return axios.post(url).then(function(resp){
store.dispatch({
type: ''MAKE_WITHDRAWL'',
action: resp.data
}) // do your reducer stuff
})
}

Su aplicación todavía sabe lo que está haciendo en el SPA, sin embargo, esto permitirá que la API lo dirija a dónde llamar para cualquier acción que deba realizarse. Espero eso ayude.

Answer 2

100% HATEOAS ES compatible con React & Flux, HATEOAS es compatible con Angular, HATEOAS es compatible con JQuery e incluso con JS vainilla.

HATEOAS no impone ningún requisito técnico o de implementación en un cliente consumidor.

HATEOAS es, de hecho, simplemente un concepto al que puede diseñar su API (puede usar uno de varios estándares, como HAL )

Básicamente, si puede llamar a una API, entonces puede implementar un cliente HATEOAS.

Entonces, ¿cómo llegar?

• Paso 1, ¿cómo harías normalmente una llamada API en React? Hazlo de la misma manera.
• Paso 2, interroga la respuesta.
• El paso 3, basado en la respuesta, responde en la IU de manera adecuada.

Por ejemplo, dada una llamada a la orden api /orders , obtengo la siguiente respuesta:

{
"_links": {
"self": { "href": "/orders" },
"next": { "href": "/orders?page=2" }
}
}

De esto puedo inferir que la next es una relación válida, y que si voy a ese href, de hecho recibiría una segunda página de pedidos, así que en este caso en la interfaz de usuario mostraré el siguiente botón.

Sin embargo, si hubiera recibido la siguiente respuesta:

{
"_links": {
"self": { "href": "/orders" },
}
}

Entonces podría inferir que la next relación no es válida, y en mi interfaz de usuario debería desactivar o no mostrar el siguiente botón.

No hay magia, es simplemente un cambio en el pensamiento, un nuevo paradigma.