Ho qualche problema a capire esattamente qual è il problema nella tua situazione, ma se ti sto leggendo, il tuo problema è come organizzare il tuo processo di sviluppo localmente, pur avendo la flessibilità di testare esternamente.
Per questo dico - non .
Se intendi utilizzare un gateway API, prova la tua parte del contratto - cosa succede dopo il gateway. In questo modo puoi catturare molti problemi che potrebbero rimanere nascosti altrimenti a causa del gateway API e inoltre qualsiasi tentativo di testare il gateway stesso è un esercizio inutile: stai essenzialmente testando un livello intermedio che ha già superato test molto rigorosi rispetto al tuo processo (si spera , che è) e che è progettato per nascondere / offuscare i dettagli più fini della tua API.
Nota : non sto suggerendo in alcun modo che non dovresti testare anche il risultato finale, ma credo che il tuo sforzo di test principale dovrebbe andare a testare il codice che possiedi e gestisci , non un livello di astrazione esterno. Il test della vista esterna è (IMO) per i test di integrazione e per il monitoraggio dello stato (sebbene questo sia più spesso di quanto non sia fornito dal provider del gateway API).
Per quanto riguarda come configurare e organizzare il processo, ti suggerisco di utilizzare Amazon API Gateway o la sua competizione ( Ho lavorato solo con AWS, mi dispiace). Lo scopo di questo servizio è quello di eliminare le problematiche specifiche dell'API, permettendoti di concentrarti sulla sostanza ("ti consente di portare il tuo valore" in marketspeak) del servizio.
Toccando il problema del reindirizzamento delle richieste alla macchina di sviluppo "locale" (si noti che questo non è proprio nella portata di questo sito, quindi sto "sconfinando" un po ', se lo farai), puoi sempre usare qualche VPN tecnologia per connettere il laptop al gateway API. In termini di AWS, credo che VPC dovrebbe consentire questo - dare un'occhiata a questo riferimento .
Infine, questa domanda grida "devops", motivo per cui mi piacerebbe prendere il tempo per sottolineare che qualsiasi considerazione di questo tipo viene discussa meglio con i colleghi più "sysadmin-y", poiché la loro esperienza sarà essenziale in impostazione di qualcosa di simile.