2016-01-26 23 views
31

Có một chức năng trong dịch vụ web REST của tôi hoạt động với phương thức GET và có hai tham số tùy chọn.Cách xác định tham số tùy chọn trong đường dẫn bằng cách sử dụng swagger

Tôi đã cố gắng xác định nó trong Swagger nhưng tôi gặp lỗi, Không phải định nghĩa thông số hợp lệ, sau khi tôi đặt requiredfalse.

Tôi phát hiện ra rằng nếu tôi đặt giá trị requiredtrue thì lỗi sẽ biến mất. Đây là một mẫu mã Swagger của tôi.

... 
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 

Tôi không gặp vấn đề này với các tham số trong nội dung hoặc thông số trong truy vấn. Tôi nghĩ rằng vấn đề này chỉ liên quan đến các tham số trong đường dẫn. Tôi cũng không thể tìm thấy bất kỳ giải pháp nào trong các tệp đặc tả swagger.

Có cách nào khác để xác định tham số tùy chọn trong Swagger hay tôi có bất kỳ sai sót nào trong mã của mình không?

Mọi trợ giúp sẽ được đánh giá cao.

Trả lời

28

Cho rằng tham số con đường phải được yêu cầu theo spec OpenAPI/Swagger, bạn có thể cân nhắc việc thêm 2 điểm cuối riêng biệt với các đường dẫn sau:

  • /get/{param1}/{param2} (khi param2 được cung cấp)
  • /get/{param1}/(khi param2 không được cung cấp)
+1

Vui lòng tham khảo https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#fixed-fields-7 –

+0

@Hedeshy nếu đây là câu trả lời đúng, vui lòng đánh dấu câu trả lời là chính xác. Cảm ơn. –

+0

Tôi đã thực sự chờ đợi một câu trả lời tốt hơn gây ra theo cách này bạn sẽ cần phải lặp lại tất cả mọi thứ. Tuy nhiên, có vẻ như đây là lựa chọn duy nhất cho bây giờ. – Hedeshy

17

Nó có khả năng phát nổ vì bạn không thể có tham số uri cơ sở tùy chọn, chỉ các giá trị chuỗi truy vấn (trong trường hợp url).

Ví dụ:

  • GET/products/{id}/giá foo = bar
  • ** Nếu foo được tùy chọn sau đó tham số IN cần phải được "truy vấn" không phải là "con đường"
  • ** Nếu {id} là tùy chọn thì có gì đó không ổn. {id} không thể là tùy chọn vì nó nằm trong uri cơ bản.

này nên làm việc:

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

này không nên làm việc

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

thay đổi của bạn "trong" tài sản để được "truy vấn" thay vì "con đường" và nó sẽ làm việc.

+0

Cảm ơn bạn @Jerrod cho câu trả lời của bạn, nhưng tôi sợ nó không giải quyết được vấn đề. Khách hàng muốn các tham số trong đường dẫn, tôi không thể đặt chúng trong truy vấn chỉ vì không thể tạo tài liệu theo cách thích hợp. – Hedeshy

+1

Thật không may tôi không nghĩ rằng bạn sẽ có thể có một tham số tùy chọn trong "đường dẫn". Nó không phải là một điều Swagger, mà là cách lược đồ URL hoạt động. Nếu bạn có GET/products/{id} và bạn nói rằng {id} là tùy chọn thì bạn đã thay đổi hoàn toàn url mà tài nguyên đang nhắm mục tiêu (tức là bây giờ là GET/products). Có lẽ bạn có thể lấy lại cho họ và hỏi họ tại sao họ muốn một tham số tùy chọn trong cơ sở uri. Tôi làm việc với REST API rất nhiều và điều này nghe có vẻ giống như một trường hợp mà yêu cầu/tài nguyên có thể cần phải suy nghĩ nhiều hơn một chút để giải quyết vấn đề. Chúc may mắn! –

+0

Truy vấn có hoạt động không nếu tôi có các điểm cuối sau: /chuỗi truy vấn tài nguyên và/tài nguyên/{id}? Có thể {id} được phân biệt với tham số truy vấn không? – Gobliins

3

YAML của bạn không thành công vì khi nó được ghi trên thông số kỹ thuật:

Xác định xem thông số này có bắt buộc hay không. Nếu tham số nằm trong "đường dẫn", thuộc tính này là bắt buộc và giá trị của nó PHẢI là đúng.

Nguồn: http://swagger.io/specification/#parameterObject (Nhìn vào lĩnh vực cố định bảng)

Các vấn đề liên quan