Hardcoding sul frontend

Question

Hardcoding sul frontend

#1 da (3 voti)
#2 da (0 voti)

1

Ho un'API che restituisce una lista di articoli. Un articolo può avere tre stati: Approvato, In sospeso e Rifiutato. Ora il front-end deve raggiungere l'API nei seguenti scenari:

Ottieni tutti gli articoli indipendentemente dallo stato.
Ricevi tutti gli articoli aggiunti da un utente.
Ricevi tutti gli articoli aggiunti da un utente che sono in sospeso / rifiutati.
Ricevi tutti gli articoli in sospeso.

Ci sono due pulsanti sul front-end: uno per il recupero di tutti gli articoli in sospeso in modo che possano essere approvati (disponibile solo per gli utenti amministratori). Un altro per il recupero di tutti gli articoli rifiutati e in sospeso per l'utente che ha effettuato l'accesso in modo che possa vedere i suoi articoli in sospeso / rifiutati. Questi due pulsanti sono disponibili nella pagina di elenco di articoli, ad esempio API è già stata premuta per recuperare tutti gli articoli ei pulsanti sono più simili ai filtri ora.
È consigliabile tornare seguendo la dict insieme all'elenco di tutti gli articoli della prima chiamata API:

{
  "admin_approval": ["Pending"],
  "self_view": ["Pending", "Rejected"]
}

In questo modo il front-end può sapere qual è lo stato di tutti gli stati che devono essere passati nei parametri della query per filtrare i risultati dei pulsanti successivi? Oppure la logica che decide quali filtri applicare è codificata su front-end?

P.S Utilizzo di Django per il back-end e Angolare per il front-end.

api rest front-end django backend

posta rohanagarwal 08.06.2017 - 09:32

fonte

2 risposte

0

È una soluzione migliore per passare i valori attesi piuttosto che il codice rigido nel front-end. In futuro, potresti avere un altro stato / stato possibile. Sarà molto più facile per il back-end passare questo nuovo valore e l'interfaccia utente per gestirlo dinamicamente visualizzando un altro pulsante o un menu a discesa.

risposta data 08.06.2017 - 09:43

fonte

Leggi altre domande sui tag api rest front-end django backend

Come posso attendere su più processi tra gli utenti? Strategia per implementare il Multiple Dispatch

score 3 · Accepted Answer

La risposta a questo dipende dalla misura in cui si desidera che l'interfaccia utente affronti le future modifiche dei requisiti, ad esempio pulsanti aggiuntivi per diversi tipi di filtri. Per le applicazioni banali, la maggior parte delle persone applicherà l'oggetto di filtraggio hard-code in ogni pulsante. Tuttavia, se vuoi che il sistema sia estensibile e hai un controllo totale sull'API REST, ti suggerisco di aggiungere un altro endpoint API che restituisca tutte le modalità di filtro supportate. Quindi, fondamentalmente, avrai

Endpoint REST per il recupero di tutti gli articoli: come http://your-machine/api/v1/articles
Endpoint REST per il recupero di tutte le modalità di filtro supportate: come http://your-machine/api/v1/filters

Il secondo endpoint restituirà quindi un array che dispone di informazioni sufficienti per il rendering dei pulsanti e saprà quali filtri applicare quando si fa clic su uno qualsiasi dei pulsanti:

[
    {
        "name": "wait_for_approval",
        "buttonText": "Await Approval",
        "filtersBy": [ ... ]
    },
    {
        "name": "self_pending_rejected",
        "buttonText": "Pending or Rejected",
        "filtersBy": [ ... ]
    },
    ...
]

Con questo approccio, è

a prova di futuro poiché il tuo endpoint può restituire un array più grande quando cambiano i requisiti.
clean in quanto impedisce anche di inquinare il primo endpoint REST.
flessibile : se si hanno utenti con ruoli diversi, l'endpoint REST deve semplicemente controllare le credenziali e restituire array diversi a seconda di quale utente effettua una richiesta.