Dove e come archiviare gli URL in un modulo Web?

Question

Dove e come archiviare gli URL in un modulo Web?

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

0

Situazione

Attualmente sto rifattorizzando il codice web esistente. Il codice attualmente ruota intorno a un oggetto ServerConfiguration . Sembra qualcosa del genere:

string UrlBase = "https://myserver.com/api"
string UrlLogin = "/v1/login";
string UrlProjects = "/v1/projects?api_token={0}";

public string GetLoginUrl()
    {
        return UrlBase + UrlLogin;
    }


public string GetProjectsUrl(string apiToken)
    {
        return string.Format(UrlBase + UrlProjects, apiToken);
    }

L'API a cui si sta accedendo è stata creata appositamente per questa app. Pertanto, non esiste un set completo di funzionalità CRUD, ma solo un set limitato di URL. La maggior parte delle cose può essere letta solo, altre cose possono essere salvate, ma su un altro link ecc.

Problema

Probabilmente i metodi dovrebbero restituire Uri anziché string , ma il mio problema è più che non riesco a trovare il posto giusto in cui questa informazione appartiene. Da un lato, è bello avere tutti i link in un posto e avere un posto dove cambiare l'indirizzo del server, nel caso dovesse mai spostarsi.

Mettere un link in es. un proprio oggetto LoginRequest si sentirebbe più orientato agli oggetti, ma duplicherebbe anche la parte UrlBase in ogni richiesta e violerebbe DRY.

Domanda

Dove archiviare gli URL?
La mia ipotesi è che probabilmente ci sono più API dedicate, limitate e limitate come questa là fuori di API CRUD per le imprese complete . Quindi probabilmente esiste un modo consolidato e idiomatico di memorizzare i collegamenti quando si oggettivizzano le richieste web. Forse ci sono anche diverse scuole di pensiero distinte. Tuttavia, dato che il mio google non ha rivelato alcuna informazione in merito, non so nemmeno dove mi trovo con la mia attuale soluzione.

object-oriented api web-services

posta R. Schmitz 04.04.2018 - 12:24

fonte

2 risposte

1

Come già affermato da Ewan, l'URL di base appartiene alle impostazioni dell'applicazione. Anche se non utilizzi URI diversi per ambienti diversi e anche se sei sicuro che l'URI non cambierà (come, ad esempio, quando accedi ad Amazon S3), è comunque una buona idea tenerlo nel impostazioni, al fine di rendere esplicito quali servizi l'applicazione dipende.

Da lì, la classe responsabile delle impostazioni dovrebbe restituire un Uri contenente l'URL di base.

La classe che hai citato nella tua domanda, come hai suggerito, restituirà anche Uri s. Se UrlLogin e UrlProjects vengono usati una sola volta nel codice, li inserirò, cioè li inserirò direttamente nei rispettivi metodi.

public Uri GetLoginUrl()
{
    return new Uri(appConfig.BaseUri, "v1/login");
}

Nota importante:

Non occuparti di string s, ma affidati a Uri s e sfrutta le capacità del framework per svolgere le difficili attività. In questo caso, il compito difficile è la corretta concatenazione degli URI. Nel tuo codice, c'è un bug : https://myserver.com/api e /v1/login dovrebbero dare https://myserver.com/v1/login , perché è così che funzionano gli URI. Il tuo codice, tuttavia, restituisce un risultato errato e sarà ancora peggio se /v1/login viene sostituito da v1/login .

risposta data 04.04.2018 - 13:07

fonte

Leggi altre domande sui tag object-oriented api web-services

Pattern per la cache di risposta del servizio Web, ma utilizza solo la cache per quando l'archivio dati si interrompe o altrimenti viene eseguita la richiesta Un servizio di dominio può anche essere una fabbrica?

score 0 · Accepted Answer

string UrlLogin = "/v1/login";
string UrlProjects = "/v1/projects?api_token={0}";

Questi sono entrambi parte della definizione dell'API e possono essere codificati nella libreria del client. Sta al cliente sapere quale endpoint chiamare quando viene chiamato il metodo Login

string UrlBase = "https://myserver.com/api"

Questo dovrebbe essere passato al costruttore della libreria client e memorizzato in un file di impostazioni dell'app che sta usando il client.

Il codice client non è a conoscenza di dove viene distribuita la Api per la sua chiamata e probabilmente si desidera utilizzare URL diversi per l'app che utilizza il client. Ad esempio, il tuo ambiente di test potrebbe puntare a https://myapi.testserver.com rispetto a https://myapi.liveserver.com quando distribuito in live

es:

public class myClient
{
    private readonly string UrlLogin = "/v1/login";
    private readonly string UrlBase
    public myClient(string baseUrl)
    {
        this.UrlBase = baseUrl;
    }

    public string Login()
    {
        var token = httpclient.Get(this.UrlBase + this.UrlLogin)
        return token;
    }


}

public class myApp()
{
    public void Main()
    {
        var url = ConfigurationManager.AppSettings["baseurl"];
        var client = new myClient(url);
        var token = client.Login();
    }
}