L'idea del pattern chain-of-command è di costruire una catena di handler e passare un comando lungo questa catena finché uno dei gestori non gestisce il comando. Questo comportamento si trova in genere nell'elaborazione degli eventi, dove, per esempio, un evento click da un pulsante dell'interfaccia utente attiva la gerarchia degli elementi dell'interfaccia utente finché non raggiunge un elemento a cui è associato un rispettivo gestore. Questo gestore può quindi decidere se gestisce il comando - terminando efficacemente l'elaborazione dell'evento - o meno - nel qual caso l'evento viene propagato ulteriormente lungo la catena.
Supponiamo ora di utilizzare tale modello per la tua web API. Quello che descrivi suona come una classica interfaccia CRUD (L) per me, dove le tue azioni sono (un sottoinsieme di) creare, leggere, aggiornare ed eliminare. Dici di avere richieste di cancellazione e presumo che tu voglia anche qualche tipo di richiesta di aggiornamento. Supponiamo inoltre di aver scritto i rispettivi gestori hupd e hdel per queste richieste di tipi. Seguendo il modello chain-of-command, puoi creare la catena [hupd, hdel] per gestire le richieste alla tua API. Quello che succede è che ogni richiesta di aggiornamento passata nella catena viene immediatamente gestita da hupd , mentre ogni richiesta di eliminazione viene respinta da hupd e passata a hdel , che lo gestisce. Questo comportamento mostra una mappatura fissa tra azioni e gestori che rende effettivamente inutile la catena. (In effetti, la catena riduce anche le prestazioni del sistema, a causa del controllo e del passaggio di ogni richiesta di cancellazione). Perché succede? Perché non esistono due gestori responsabili di diversi sottoinsiemi di richieste con lo stesso tipo di azione. Quello che vuoi veramente avere qui è una mappatura diretta ["update" = > hupd, "delete" = > hdel] e un dispatcher che accetta le rispettive richieste e le passa direttamente al rispettivo gestore. Un tale progetto può ancora essere esteso per quanto riguarda le nuove azioni, se esiste un registro dinamico con la mappatura.
Ora potresti dire che vuoi avere gestori diversi per, per esempio, la cancellazione di elementi di tipo A e B. Che cosa ti dà gestori per sottoinsiemi di richieste con lo stesso tipo di azione. Ma ancora una volta, si ha una mappatura diretta e fissa tra i gestori e il tipo di elemento, cioè, è possibile inviare ripetutamente richieste in base al tipo di elemento di destinazione. Questo ti dà un dispatch a due livelli, dove con una chain-of-command potresti passare la richiesta attraverso il numero di azioni volte al numero di gestori di tipi di elementi, nel peggiore dei casi.
Conclusione: non raccomanderei il modello chain-of-command per implementare questo tipo di API. Affinché il pattern abbia un valore, è necessario uno scenario in cui si desidera aggiungere e rimuovere dinamicamente i gestori e in cui la condizione di quando un gestore gestisce effettivamente un evento non è esprimibile da una semplice mappatura da costanti.