Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
swagger: '2.0'
info:
version: 1.1.1
title: SOL002 - VNF Configuration interface
description: >
VNF Configuration interface of ETSI NFV SOL002
IMPORTANT: Please note that this file might be not aligned to the current
version of the ETSI Group Specification it refers to. In case of
discrepancies the published ETSI Group Specification takes precedence.
Please report bugs to
https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=---
license:
name: ETSI Forge copyright notice
url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt'
externalDocs:
description: ETSI GS NFV-SOL 002 V2.4.1
url: >-
http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf
basePath: /vnfconfig/v1
schemes:
- http
- https
consumes:
- application/json
produces:
- application/json
paths:
/configuration:
get:
summary: Read VNF/VNFC configuration from VNF.
description: >
The client can use this method to read configuration information about a
VNF instance and/or its VNFC instances.
responses:
'200':
description: >
OK
Configuration information about a VNF instance was read
successfully. The response body shall contain a representation of
the configuration resource.
schema:
$ref: '#/definitions/VnfConfiguration'
'400':
description: >
Bad Request
If the request is malformed or syntactically incorrect (e.g. if the
request URI contains incorrect query parameters or a syntactically
incorrect payload body), the API producer shall respond with this
response code. The "ProblemDetails" structure shall be provided, and
should include in the "detail" attribute more information about the
source of the problem.
---
If the request contains a malformed access token, the API producer
should respond with this response. The details of the error shall be
returned in the WWW-Authenticate HTTP header, as defined in IETF RFC
6750 and IETF RFC 7235. The ProblemDetails structure may be
provided.
---
If there is an application error related to the client's input that
cannot be easily mapped to any other HTTP response code ("catch all
error"), the API producer shall respond with this response code.The
"ProblemDetails" structure shall be provided, and shall include in
the "detail" attribute more information about the source of the
problem.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
WWW-Authenticate:
description: >
Challenge if the corresponding HTTP request has not provided
authorization, or error details if the corresponding HTTP
request has provided an invalid authorization token.
type: string
maximum: 1
minimum: 0
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
A URI reference according to IETF RFC 3986 [5] that identifies
the problem type. It is encouraged that the URI provides
human-readable documentation for the problem (e.g. using HTML)
when dereferenced. When this member is not present, its value
is assumed to be "about:blank".
type: string
format: URI
title:
description: >
A short, human-readable summary of the problem type. It should
not change from occurrence to occurrence of the problem,
except for purposes of localization. If type is given and
other than "about:blank", this attribute shall also be
provided. A short, human-readable summary of the problem
type. It SHOULD NOT change from occurrence to occurrence of
the problem, except for purposes of localization (e.g., using
proactive content negotiation; see [RFC7231], Section 3.4).
type: string
status:
description: >
The HTTP status code for this occurrence of the problem. The
HTTP status code ([RFC7231], Section 6) generated by the
origin server for this occurrence of the problem.
type: integer
detail:
description: >
A human-readable explanation specific to this occurrence of
the problem.
type: string
instance:
description: >
A URI reference that identifies the specific occurrence of the
problem. It may yield further information if dereferenced.
type: string
format: URI
'401':
description: >
Unauthorized
If the request contains no access token even though one is required,
or if the request contains an authorization token that is invalid
(e.g. expired or revoked), the API producer should respond with this
response. The details of the error shall be returned in the
WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF
RFC 7235. The ProblemDetails structure may be provided.
headers:
Content-Type:
description: The MIME type of the body of the response.
type: string
maximum: 1
minimum: 1
WWW-Authenticate:
description: >
Challenge if the corresponding HTTP request has not provided
authorization, or error details if the corresponding HTTP
request has provided an invalid authorization token.
type: string
maximum: 1
minimum: 0
schema:
description: >
The definition of the general "ProblemDetails" data structure from
IETF RFC 7807 [19] is reproduced inthis structure. Compared to the
general framework defined in IETF RFC 7807 [19], the "status" and
"detail" attributes are mandated to be included by the present
document, to ensure that the response contains additional textual
information about an error. IETF RFC 7807 [19] foresees
extensibility of the "ProblemDetails" type. It is possible that
particular APIs in the present document, or particular
implementations, define extensions to define additional attributes
that provide more information about the error. The description
column only provides some explanation of the meaning to Facilitate
understanding of the design. For a full description, see IETF RFC
7807 [19].
type: object
required:
- status
- detail
properties:
type:
description: >
A URI reference according to IETF RFC 3986 [5] that identifies
the problem type. It is encouraged that the URI provides
human-readable documentation for the problem (e.g. using HTML)
when dereferenced. When this member is not present, its value
is assumed to be "about:blank".
type: string
format: URI
title:
description: >
Loading
Loading full blame…