Jak przekazać wiele parametrów do interfejsu API sieci Web ASP.Net GET?

Używam Web API .Net MVC4 do (miejmy nadzieję) zaimplementować RESTful api. Muszę przekazać kilka parametrów do systemu i zlecić mu wykonanie jakiejś czynności, a następnie zwrócić listę obiektów jako wyniki. Dokładniej mówiąc, podaję dwie daty i zwracam rekordy, które mieszczą się między nimi. Śledzę również zwracane rekordy, aby kolejne wywołania nie były ponownie przetwarzane w systemie.

Rozważyłem kilka podejść:

1. Serializowanie parametrów w jeden ciąg JSON i wybieranie ich w interfejsie API. http://forums.asp.net/t/1807316.aspx/1

2. Przekaż parametry w ciągu zapytania.
   Jaki jest najlepszy sposób przekazania wielu parametrów zapytania do spokojnego interfejsu API?

3. Definiowanie parametrów w trasie: api / controller / date1 / date2

4. Użycie POST, który z natury pozwala mi przekazać obiekt z parametrami.

5. Badanie ODATA, ponieważ obsługuje je Web API (obecnie). Nie zrobiłem jeszcze wiele z tym, więc nie jestem z tym zaznajomiony.

Wygląda na to, że właściwe praktyki REST wskazują, kiedy pobierane są dane, należy użyć GET. Jednak GET powinien również być nieulotny (nie wywołuje skutków ubocznych) i zastanawiam się, czy moja konkretna implementacja to narusza, skoro zaznaczam rekordy w systemie API, stąd generuję efekty uboczne.

Doprowadziło mnie to również do pytania o obsługę zmiennych parametrów. Jeśli lista parametrów wejściowych ulegnie zmianie, ponowne zdefiniowanie trasy dla Wyboru 3 byłoby żmudne, gdyby zdarzało się to często. A co by się stało, gdyby parametry zostały zdefiniowane w czasie wykonywania ...

W każdym razie, w przypadku mojej konkretnej realizacji, który wybór (jeśli w ogóle) wydaje się najlepszy?

Co oznacza to oznaczenie rekordu? Jeśli jest to używane tylko do celów rejestrowania, użyłbym GET i wyłączyłbym buforowanie, ponieważ chcesz rejestrować każde zapytanie dotyczące tych zasobów. Jeśli oznaczanie rekordów ma inny cel, najlepszym rozwiązaniem jest POST. Użytkownik powinien wiedzieć, że jego działania mają wpływ na system, a metoda POST jest ostrzeżeniem.

Myślę, że najłatwiej jest po prostu użyć AttributeRouting.

Jest to oczywiste w twoim kontrolerze, dlaczego chcesz to mieć w WebApiConfigpliku globalnym ?

Przykład:

    [Route("api/YOURCONTROLLER/{paramOne}/{paramTwo}")]
    public string Get(int paramOne, int paramTwo)
    {
        return "The [Route] with multiple params worked";
    }

Te {}nazwy muszą dopasować parametry.

To proste, teraz masz oddzielny, GETktóry obsługuje wiele parametrów w tym przypadku.

Po prostu dodaj nową trasę do WebApiConfigwpisów.

Na przykład, aby zadzwonić:

public IEnumerable<SampleObject> Get(int pageNumber, int pageSize) { ..

Dodaj:

config.Routes.MapHttpRoute(
    name: "GetPagedData",
    routeTemplate: "api/{controller}/{pageNumber}/{pageSize}"
);

Następnie dodaj parametry do wywołania HTTP:

GET //<service address>/Api/Data/2/10 

Po prostu musiałem zaimplementować RESTfull API, w którym muszę przekazać parametry. Zrobiłem to, przekazując parametry w ciągu zapytania w tym samym stylu, co opisano w pierwszym przykładzie Marka „api / controller? Start = date1 & end = date2”

W kontrolerze użyłem wskazówki z podziału adresu URL w C #?

// uri: /api/courses
public IEnumerable<Course> Get()
{
    NameValueCollection nvc = HttpUtility.ParseQueryString(Request.RequestUri.Query);
    var system = nvc["System"];
    // BL comes here
    return _courses;
}

W moim przypadku dzwoniłem do WebApi przez Ajax, wyglądając tak:

$.ajax({
        url: '/api/DbMetaData',
        type: 'GET',
        data: { system : 'My System',
                searchString: '123' },
        dataType: 'json',
        success: function (data) {
                  $.each(data, function (index, v) {
                  alert(index + ': ' + v.name);
                  });
         },
         statusCode: {
                  404: function () {
                       alert('Failed');
                       }
        }
   });

Mam nadzieję, że to pomoże...

Znalazłem doskonałe rozwiązanie na http://habrahabr.ru/post/164945/

public class ResourceQuery
{
   public string Param1 { get; set; }
   public int OptionalParam2 { get; set; }
}

public class SampleResourceController : ApiController
{
    public SampleResourceModel Get([FromUri] ResourceQuery query)
    {
        // action
    }
}

Używanie GET lub POST jest jasno wyjaśnione przez @LukLed . Jeśli chodzi o sposoby przekazywania parametrów, sugerowałbym skorzystanie z drugiego podejścia (też nie wiem zbyt wiele o ODATA ).

1.Serializowanie parametrów w jeden ciąg JSON i rozbieranie go w interfejsie API. http://forums.asp.net/t/1807316.aspx/1

To nie jest przyjazne dla użytkownika i przyjazne dla SEO

2. podaj parametry w ciągu zapytania. Jaki jest najlepszy sposób przekazania wielu parametrów zapytania do spokojnego interfejsu API?

Jest to zwykle preferowane podejście.

3. Definiowanie parametrów w trasie: api / controller / date1 / date2

To zdecydowanie nie jest dobre podejście. To sprawia, że ​​ktoś date2jest zasobem podrzędnym, date1a tak nie jest. Oba parametry zapytania date1i date2są parametrami zapytania i znajdują się na tym samym poziomie.

W prostym przypadku zasugerowałbym taki URI,

api/controller?start=date1&end=date2

Ale osobiście podoba mi się poniższy wzorzec URI, ale w tym przypadku musimy napisać niestandardowy kod, aby zmapować parametry.

api/controller/date1,date2

Użyj powiązania parametrów zgodnie z pełnym opisem tutaj: http://www.asp.net/web-api/overview/formats-and-model-binding/parameter-binding-in-aspnet-web-api

 [Route("api/controller/{one}/{two}")]
    public string Get(int One, int Two)
    {
        return "both params of the root link({one},{two}) and Get function parameters (one, two)  should be same ";
    }

Oba parametry linku głównego ({jeden}, {dwa}) i parametry funkcji Get (jeden, dwa) powinny być takie same

Wiem, że to jest naprawdę stare, ale ostatnio chciałem tego samego i oto co znalazłem ...

    public HttpResponseMessage Get([FromUri] string var, [FromUri] string test) {
        var retStr = new HttpResponseMessage(HttpStatusCode.OK);
        if (var.ToLower() == "getnew" && test.ToLower() == "test") {
            retStr.Content = new StringContent("Found Test", System.Text.Encoding.UTF8, "text/plain");
        } else {
            retStr.Content = new StringContent("Couldn't Find that test", System.Text.Encoding.UTF8, "text/plain");
        }

        return retStr;
    }

Więc teraz w twoim adresie / URI / ...

http (s): // myURL / api / myController /? var = getnew & test = test

Wynik: „Znaleziono test”

http (s): // myURL / api / myController /? var = getnew & test = cokolwiek

Wynik: „Nie udało się znaleźć tego testu”

Teraz możesz to zrobić, używając po prostu

        public string Get(int id, int abc)
        {
            return "value: " + id + "  " + abc;
        }

to zwróci: „wartość: 5 10”

jeśli zadzwonisz za pomocą https: // twoja_domena / api / yourcontroller? id = 5 & abc = 10

    public HttpResponseMessage Get(int id,string numb)
    {
        //this will differ according to your entity name
        using (MarketEntities entities = new MarketEntities())
        {
          var ent=  entities.Api_For_Test.FirstOrDefault(e => e.ID == id && e.IDNO.ToString()== numb);
            if (ent != null)
            {
                return Request.CreateResponse(HttpStatusCode.OK, ent);
            }
            else
            {
                return Request.CreateErrorResponse(HttpStatusCode.NotFound, "Applicant with ID " + id.ToString() + " not found in the system");
            }
        }
    }