Re-trasformazione dei dati per l'API da consumare

Question

Re-trasformazione dei dati per l'API da consumare

#1 da (0 voti)

1

Dopo aver creato un paio di API moderatamente complesse, entrambe in Laravel, apprezzo il valore della trasformazione dei dati prima di inviarli in una risposta.

Ciò di cui sto combattendo è come devono essere gestiti questi dati quando ritorna, quindi per creare e soprattutto aggiornare i metodi. Dovrebbe essere trasformato (ma al contrario)?

Ad esempio, supponiamo di avere il seguente trasformatore di attività:

class ContractTransformer extends Transformer
{
    /**
     * @param $task
     * @return array
     */
    public function transform($task)
    {
        return [
            'id'           => $task['id'],
            'title'        => $task['title'],
            'description'  => $task['description'],
            'due_date'     => $task['end_date']
        ];
    }
}

Si noti che il valore per la colonna 'end_date' nel database viene restituito come 'due_data' - un esempio primitivo di restituzione del nome della colonna in un modo più intuitivo.

Diciamo che un utente che utilizza questa API e costruisce il front-end con Angular / React o un altro framework, riceve un valore per 'due_date' e quindi sicuramente si aspetterebbe di rimandarlo (per un'operazione di aggiornamento) come ' due_date 'anziché' end_date '?

Quindi abbiamo il problema (specialmente per oggetti di grandi dimensioni con molti campi) di dovendo fare qualcosa di simile al seguente:

$task = Task::find($id);
        $task->title = $request->input('title');
        $task->description = $request->input('description');
        // and so on...
        $task->save();

Piuttosto che usare:

$request->all();

E significa che se cambiano i nomi delle colonne dobbiamo aggiornare anche tutti i metodi di aggiornamento.

C'è un buon modo per gestirlo? I dati dovrebbero essere "ri-trasformati"?

api-design php rest laravel

posta C Ivemy 21.09.2017 - 15:11

fonte

1 risposta

Leggi altre domande sui tag api-design php rest laravel

Interfaccia del processore Camel su classe astratta Come dovrei gestire la chiave privata nel responsabile della decrittografia?

score 0 · Accepted Answer

Risposta breve: sì, quando si interagisce con l'interfaccia utente (o il database o qualsiasi altro sistema esterno), dovresti fare sostanzialmente ciò che hai descritto qui.

In un'applicazione web non banale, di solito hai almeno tre sottosistemi principali:

una sorta di front-end che si occupa dell'interazione dell'utente
un livello aziendale che implementa qualunque sia lo scopo dell'applicazione
una sorta di livello di accesso ai dati

Ciascuno di questi componenti avrà generalmente esigenze diverse per la struttura dei dati. Per mantenere questi sistemi separati (e quindi mantenibili), nessuno dei sistemi dovrebbe nemmeno essere consapevole del modo in cui gli altri rappresentano i loro dati.

Invece, comunicano passando semplici DTO tra loro, proprio come hai mostrato nei tuoi esempi. Quindi per ogni azione, si definisce una richiesta-DTO e un DTO di risposta. Su entrambi i lati dell'API, li converti in qualunque cosa ti serva.

Questo può sembrare un sacco di lavoro, ma considera:

Dovrai comunque eseguire la convalida dell'input e queste attività vanno bene insieme
Quando modifichi la rappresentazione interna di un sistema, tutto ciò che devi fare è aggiornare i metodi di conversione di quel sistema, piuttosto che dappertutto.
Puoi incapsulare correttamente il tuo stato nel modello di dominio, cioè avere una classe Task piuttosto che un array accessibile a tutti. E potresti avere più oggetti da cui è stato costruito il tuo DTO, quindi spesso non è un mapping 1: 1.

Tutto questo viene detto, se la tua applicazione è semplice e si finisce essenzialmente per convertire solo una matrice in un'altra, non si può beneficiare di questa separazione rigorosa.

Considerazioni finali:

Rendi l'API coerente: se si chiama due_date che esce, allora dovrebbe anche chiamarsi due_date in entrata - nello stesso formato, ecc.
Se converti spesso strutture di dati molto grandi, è possibile che esiste un design migliore con strutture di dati più piccole. Ad esempio, invece di avere un'azione UpdateTask che modifica 30 valori, ci potrebbe avere valore sostituendo questo con molte azioni più piccole, come UpdateTaskDueDate ecc. Questo dipende molto dalle tue esigenze ...

Questo articolo potrebbe anche essere interessante per te - l'ultima parte tratta di come e perché utilizzare DTO piuttosto che qualsiasi struttura di dati che hai nel tuo livello aziendale.