Jak zdefiniować opcjonalny parametr w ścieżce za pomocą funkcji przekierowania?

W mojej usłudze WWW REST działa funkcja z metodą GET i ma dwa opcjonalne parametry.Jak zdefiniować opcjonalny parametr w ścieżce za pomocą funkcji przekierowania?

próbowałem zdefiniować go w Swagger ale wystąpił błąd, nie jest prawidłową definicję parametru, po tym, jak ustawić required jak false.

Okazało się, że jeśli ustawię wartość required jako true, błąd zniknie. Oto próbka mojego kodu Swagger.

... 
paths: 
    '/get/{param1}/{param2}': 
    get: 
     ... 
     parameters: 
     - name: param1 
     in: path 
     description: 'description regarding param1' 
     required: false 
     type: string 
     - name: param2 
     in: path 
     description: 'description regarding param2' 
     required: false 
     type: string

Nie widziałem tego z parametrami w treści lub tymi w zapytaniu. Myślę, że ten problem dotyczy tylko parametrów w ścieżce. Nie mogłem znaleźć żadnego rozwiązania w plikach specyfikacji swagger.

Czy istnieje inny sposób definiowania opcjonalnych parametrów w Swagger lub czy mam jakiś błąd w moim kodzie?

Każda pomoc zostanie doceniona.

Źródło

2016-01-26 Hedeshy

Biorąc pod uwagę, że parametr ścieżka musi być wymagane zgodnie ze specyfikacją OpenAPI/Swagger, można rozważyć dodanie 2 oddzielne punkty końcowe z następujących ścieżek:

/get/{param1}/{param2} (gdy param2 jest)
/get/{param1}/(gdy param2 nie jest dostarczany)

Źródło

2016-01-27 06:20:54

Proszę odnieść się do https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#fixed-fields-7 –

@Hedeshy, jeśli jest to poprawna odpowiedź, proszę oznaczyć ją jako poprawną. Dzięki. –

Tak naprawdę czekałem na lepszą odpowiedź, ponieważ w ten sposób będziesz musiał wszystko powtórzyć. Jednak wydaje się, że jest to jedyna opcja na teraz. – Hedeshy

Prawdopodobnie wysadzenie w powietrze, ponieważ nie można podać opcjonalnego parametru bazowego uri, a jedynie wartości ciągu zapytania (w przypadku adresu URL).

Na przykład:?

GET/produkty/{id}/wycena foo = bar
** Jeśli foo jest opcjonalny wówczas parametr IN musi być "query" nie "ścieżka"
** Jeśli {id} jest opcjonalne, oznacza to, że coś jest nie tak. {id} nie może być opcjonalne, ponieważ jest zawarte w bazie URI.

To powinno działać:

{ 
"in":"query", 
"required":false 
}

To nie powinno działać

{ 
"in":"path", 
"required":false 
}

zmienić "w" własności jako "zapytanie" zamiast "ścieżki" i powinno działać.

Źródło

2016-01-26 14:55:18

dziękuję @Jerrod za odpowiedź, ale obawiam się, że to nie rozwiązuje problemu. Klient chciał parametrów w ścieżce, nie mogę umieścić ich w zapytaniu tylko dlatego, że nie jest możliwe stworzenie dokumentacji w odpowiedni sposób. – Hedeshy

Niestety nie sądzę, że będziesz mieć opcjonalny parametr w "ścieżce". To nie jest sprawa Swaggera, ale raczej sposób działania schematu URL. Jeśli masz GET/products/{id} i mówisz, że {id} jest opcjonalne, całkowicie zmieniłeś adres URL, na który kieruje się zasób (tj. Teraz GET/produkty). Być może mógłbyś zwrócić to do nich i zapytać ich, dlaczego chcą opcjonalnego parametru w bazie uri. Pracuję z API REST bardzo często i to brzmi jak przypadek, w którym żądanie/zasób może wymagać trochę więcej wysiłku, aby rozwiązać problem. Powodzenia! –

Czy zapytanie działa, jeśli mam następujące punkty końcowe: /resource? Querystring i/resource/{id}? Czy {id} można odróżnić od parametrów zapytania? – Gobliins

Twój YAML powiodło się, ponieważ jak stwierdzono na specyfikacji:

Określa, czy ten parametr jest obowiązkowy. Jeśli parametr znajduje się w "path", ta właściwość jest wymagana, a jej wartość MUSI być prawdziwa.

Źródło: http://swagger.io/specification/#parameterObject (Spójrz w stałych pól stołowych)

Źródło

2016-03-08 22:09:55

Jak zdefiniować opcjonalny parametr w ścieżce za pomocą funkcji przekierowania?

Odpowiedz

Powiązane problemy