REST (HATEOAS) e ReactJS

Question

Sono interessato all'utilizzo del principio HATEOAS di REST per ridurre la logica di business in un'applicazione SPA. In un contesto specifico di React, mi piacerebbe sapere se ci sono sfide che rendono questo non pratico e, in caso contrario, quale è una buona strategia da seguire?

esempi concettuali di utilizzare hateoas per rimuovere la logica di business dalla UI:

• Delegating valid bank account actions to the REST service
• Delegating role-based access control to the REST service

ho trovato un link che suggerisce React/Flux is not compatible with a HATEOAS strategy, e nessun dibattito significativo altrove solo . Non è davvero fattibile in un'app React/Flux? Quel post SO non ha ricevuto abbastanza attenzione. Qualcuno ha un approccio preferito o consigliato per raggiungere il successo (con o senza Flux o Redux)?

Qualcuno ha fornito un esempio abbastanza dettagliato di leveraging HATEOAS in the context of Angular. Sto cercando qualcosa di simile per React.

Personalmente, sto immaginando il tag rel nei collegamenti ipermediali che controllano quali componenti JSX sono resi (conditional JSX). È così ingenuo per un'app React reale? Forse i rendering condizionali dei componenti React sono troppo grossolani per essere usati in questo modo?

Suppongo che i collegamenti ipermediali siano forniti da un'implementazione HAL o che siano conformi alla convenzione di feed ATOM (RFC4287).

Answer 1

Prima di sputare la mia risposta più probabile errata/irrilevante, voglio solo farti sapere che ho appena letto su cosa sia HATEOAS. Quell'avvertimento lì, da quello che ho brevemente letto, HATEOAS sembra essere principalmente sull'API che ti dice come navigare attraverso se stesso fornendo un link alle risorse che sono rilevanti per la risorsa che hai appena richiesto.

In questo caso, non vedo un motivo per cui non è possibile implementare chiamate ajax url dinamiche nelle azioni che alterano lo stato dell'applicazione della SPA (cioè Redux) in base a ciò che è stato fornito all'utente, tuttavia , dovrai comunque avere qualcosa per rappresentare lo stato in modo visivo per tutte le parti della tua applicazione. Ecco un grezzo semi-pseudo e non molto ben rappresentazione ponderata di quello che voglio dire liberamente ispirato proprio conto bancario ad esempio:

// 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 
    }) 
} 

L'applicazione sa ancora quello che sta facendo in ZPS, tuttavia, questo permetterà al API per indirizzarti dove chiamare per qualsiasi azione debba essere eseguita. Spero che sia d'aiuto.

Answer 2

100% HATEOAS È compatibile con React & Flux, HATEOAS è compatibile con Angular, HATEOAS è compatibile con JQuery e persino con JS vaniglia.

HATEOAS non impone alcun requisito tecnico o di implementazione a un cliente consumatore.

hateoas è infatti semplicemente un concetto che è possibile progettare l'API (è possibile utilizzare uno dei diversi standard anche se, come HAL) per

In sostanza se si può chiamare un'API, allora è possibile implementare un client hateoas.

Così come arrivare:

• Fase 1, come si fa normalmente una chiamata API a Reagire? Fallo allo stesso modo.
• Passaggio 2, interrogare la risposta.
• Il passaggio 3, in base alla risposta, risponde all'interfaccia utente in modo appropriato.

Ad esempio dato una chiamata all'ordine api /orders, ottengo la seguente risposta:

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

Da questo posso dedurre che next è una relazione valida, e che se vado a che href Avrei infatti ricevuto una seconda pagina di ordini, quindi in questo caso nell'interfaccia utente mostrare il pulsante successivo.

Tuttavia se avessi ricevuto la seguente risposta:

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

Poi mi può inferire che next non è una relazione valida, e nel mio UI dovrei disabilitato o non visualizzare un pulsante accanto.

Non c'è magia, è semplicemente un cambiamento nel modo di pensare, un nuovo paradigma.