Documentation update for TMF 633 API - POST /serviceSpecification

Issue-ID: EXTAPI-486

Change-Id: I4a2f8d663a5c1f57f0055cbbaf2f9d5f253e67a7
Signed-off-by: renrak15 <renrak15@gmail.com>

1 files changed, 14 insertions, 3 deletions

diff --git a/docs/offeredapis/offeredapis.rst b/docs/offeredapis/offeredapis.rst
index 0d1bb04..c55d5a9 100644
--- a/docs/offeredapis/offeredapis.rst
+++ b/docs/offeredapis/offeredapis.rst
@@ -130,7 +130,6 @@ is provided - Swagger is documented.
 
 Only ``serviceSpecification`` resource is provided.
 Information are retrieved in **SDC** (and in TOSCA file)
-- Only GET operation is provided - this API does not update **SDC**.
 
 Only characteristics at service level will be retrieved in ONAP TOSCA file.
 For example if an ONAP service is composed of VNF and the VF module, the
@@ -161,7 +160,7 @@ If no ``serviceSpecification`` matches, an empty list is send back.
 Example: ``GET /nbi/api/v4/serviceSpecification/{uuid}``
 
 It is use to retrieve one ``serviceSpecification`` - all available information
-are retieved (see Swagger for description)
+are retrieved (see Swagger for description)
 
 **GET service Specification Schema (id)**
 
@@ -169,7 +168,19 @@ Example:
 ``GET /nbi/api/v4/serviceSpecification/{uuid}/specificationInputSchema``
 
 It is use to retrieve one  input schema from the tosca file stored in **NBI**
-- all available information are retieved (see Swagger for description)
+- all available information are retrieved (see Swagger for description)
+
+**POST service Specification**
+
+Example:
+
+``POST /nbi/api/v4/serviceSpecification``
+
+This operation creates a ``serviceSpecification`` in catalog (see Swagger for description)
+It is used to provide a consistent way of on-boarding third party services to SDC via External API
+
+Only *primitive type* service characteristics are supported as part of this release. Further enhancements
+need to be made on other modules of ONAP for ensuring e2e automation of third party services. 
 
 ----------------
 serviceInventory