REST GET-Anfrage: Ist es in Ordnung, Anfrage String-Parameter als Antwort zu erwarten, um die Berechnung auf Client-Seite zu vermeiden

Question

Wir haben eine API, die Bewertung von elektronischen Artikel basierend auf Hersteller, Jahr der Herstellung, Ort des Kaufs gibt.

In der Antwort erhalten wir zwei Preise, schlechter Preis (wenn Produkt wenig Schäden hat) und guten Preis (falls Produkt fast neu ist). Wir zeigen diese zwei Preise zusammen mit Details der ursprünglichen elektronischen Artikel in neuen Bildschirm wie:

Originalartikel Hersteller, Jahr der Herstellung, Stadt des Kaufs.

UND schlechter Preis und guter Preis.

Wir haben dieses Eingabeformular, wo Benutzer Details füllt, klicken Sie auf "Get Valuation Button". Dann treffen wir auf unsere Bewertungs-API, die uns die Ergebnisse zurückgibt.

Jetzt haben wir zwei Möglichkeiten für die Antwort von valution API:

1. Keep only bad price and good price in response AND extract Original item manufacturer, year of manufacturing, city of purchase from input query string to API from client. 

Pro dieses Ansatzes: Einfach und ordentlich. Sieht offensichtlich aus.

Con: Aber Problem ist, dass jeder Client (Schreibtisch, Handy, Android, IOS) muss Benutzereingaben auswählen und sie in Ausgabebildschirm verwenden.

Pro: Keine Notwendigkeit, Informationen aus api-Eingaben auszuwählen und an den Ausgabebildschirm zu übergeben. Die Antwort für den 2. Bildschirm ist abgeschlossen.

Con: Der Client erwartet, dass der Server die Daten, die er bereits hatte, zurücksendet.

Welcher Ansatz ist besser? Welches sollten wir wählen?

Answer 1

Idealerweise würde ich der Antwort einige benutzerdefinierte Header hinzufügen, die die Daten enthalten, die der Client für die Berechnung benötigt. Zum Beispiel im Falle eines Erhaltungs-Anforderung, wo ich Paging unterstützen würde ich eine Paginierung Header der Antwort so etwas wie hinzufügen:

public static class ApiExtensions 
{ 
    #region Fields 

    private static string X_PAGINATION_HEADER = "X-Pagination"; 

    #endregion 

    /// <summary> 
    /// Adds a header to the current response with the pagination data 
    /// </summary> 
    /// <param name="headers">Current response header collection</param> 
    /// <param name="query">Query executed</param> 
    /// <param name="queryResult">Query result</param> 
    /// <param name="urlHelper">Url helper to create next/previous links</param> 
    /// <param name="routeName">Current executing route</param> 
    /// <returns>Current response headers with pagination data</returns> 
    public static NameValueCollection AddPaginationHeader(this NameValueCollection headers, IQuery query, IQueryResult queryResult, UrlHelper urlHelper, string routeName) 
    { 
     dynamic dQuery = query; 
     dynamic dResult = queryResult; 
     var totalPages = (int)Math.Ceiling((double)dResult.TotalCount/dQuery.PageSize); 
     var previousLink = (dQuery.Page > 1) ? urlHelper.Link(routeName, new 
     { 
      sortParams = dQuery.SortParams, 
      page = (dQuery.Page - 1), 
      pageSize = dQuery.PageSize, 
      userId = dQuery.UserId 
     }) : ""; 


     var nextLink = (dQuery.Page < totalPages) ? urlHelper.Link(routeName, new 
     { 
      sortParams = dQuery.SortParams, 
      page = (dQuery.Page + 1), 
      pageSize = dQuery.PageSize, 
      userId = dQuery.UserId 
     }) : ""; 

     var paginationHeader = new 
     { 
      currentPage = dQuery.Page, 
      pageSize = dQuery.PageSize, 
      totalPages = totalPages, 
      nextLink = nextLink, 
      previousLink = previousLink 
     }; 

     headers.Add(X_PAGINATION_HEADER, JsonConvert.SerializeObject(paginationHeader)); 
     return headers; 
    } 
} 

Und dann diese Erweiterung Methode in meinem Controller aufrufen, bevor die Antwort zurückgibt:

HttpContext.Current.Response.Headers.AddPaginationHeader(query, result, new UrlHelper(Request), "datalist"); 
      return Ok(result);