Come posso refactoring funzionalità lato client per creare un design generico come linea di prodotti?

Bene, il lato client è ancora servito dal server delle applicazioni, non è vero? Quindi in pratica quello di cui hai bisogno è la capacità di fornire alcuni parametri.

Ovviamente dovrai sostituire l'URL del server. La maggior parte dell'aspetto può essere modificata semplicemente caricando i fogli di stile appropriati (CSS), che è solo un altro URL sostituito. E un altro URL sostituito può darti la personalizzazione di JavaScript con parametri ed eventualmente sostituzioni ad alcune funzioni.

Questo dovrebbe essere sufficiente per la maggior parte degli scopi, ma nella pratica condizionatamente includere alcuni bit dell'HTML potrebbe essere più facile da mantenere, perché le varianti sono proprio lì in un posto anziché distribuite su file JavaScript con personalizzazione e un altro file JavaScript che modifica il DOM di conseguenza.

Sembra che tu abbia creato un'applicazione web in modo simile ai sistemi di gestione dei contenuti (CMS). Nei sistemi CMS come DotNetNuke (DNN) si dispone di una configurazione di servizio (spesso chiamata portale o sito) che consente di configurare DNS, DB, Stili / skin su ogni istanza dell'applicazione in esecuzione. I moduli di codice (la tua comunanza) rimangono gli stessi, ma ogni "istanza" include un'impostazione che inietta skin (CSS + images) e basi di archiviazione di URL e DB.

Invariabilmente devi decidere in che modo i tuoi / clienti vorranno configurare tali funzioni e ciò imporrà il modo in cui archivierai e recupererai le impostazioni (la tua variabilità). Ho il sospetto che tu abbia già identificato le parti di variabilità e che sia solo un caso di refactoring della soluzione per consentire a tali parti di essere memorizzate / recuperate come qualsiasi altra parte della tua applicazione.

The RESTful URLs where the requests are sent

Questo è solo un semplice caso in cui gli URL sono simili a:

• link
• link
• ecc.

(significa che la base dell'API è variabile, ma i percorsi all'interno non lo sono)? In questo caso, in pratica il tuo chiamante REST dovrebbe fare ${apibase}/api/post e inserire valori diversi per apibase nel posto giusto (configurazione dell'istanza dell'applicazione).

The text/style of the UI

Essere in grado di definire diversi CSS e testo. I CSS dovrebbero essere facili, per testi brevi potresti probabilmente adattare le funzionalità della i18n della tua piattaforma e per lunghi testi che potresti probabilmente fare con include parametrizzabili, qualcosa di simile a:

include("path/to/mylongtextresource-${sitename}.html")

Indirizzando il tuo commento:

My ENTIRE URI is different - things ARE different in a restful world since it's very resource oriented. In your example the same 'type' of resources exist for the base resource. Yes, I do have them too and that's exactly how they are handled. But I feel the answer misses the point of the question. I need to 'structure' my code so that 'another' restful resource with 'similar structure' (e.g.,: /Site/{resource}/{id}/{sub-resource}/{id}/) can easily be added to the system with minimal changes

Userei qualcosa come il seguente (pseudo-java):

interface ResourceService {
    public String getContent(String id, String subResource, String subId);
}

Map<String,ResourceService> services = {"resourceA" : new AResourceService(), "resourceB", new BResourceService(), ...};

@URLMap("/Site/{resource}/{id}/{sub-resource}/{id}/")
String getContent(String resource, String id, String subResource, String subId) {
    return services.get(resource).getContent(id, subResource, subId);
}

Il che significa che puoi aggiungere programmaticamente nuovi ResourceService s al tuo Controller. Potresti anche farlo a due livelli, se necessario.