Response message body for REST APIs

[previousqna]

Hi Team,

How to inject content text into the response message body while invoking the RFS service points using the REST API? I am able to execute a POST which on successful service creation returns response header attributes with status code == 201 and Location.

I am also able to subsequently run a GET request using values from location response attribute to fetch details of the service that was created using POST above.

I am looking for a way to inject subset of details returned using GET (from example below) into the response content message for the POST request instead of returning an empty message body.

customer-vrf-api-create-serviceonly.json

{

    "enterpriseOnboard:customer-vrf":

        {

            "request-id": "SLRollTest999",

            "device": "WALNUTCRASR-01",

            "customer-id": 894,

            "customer-name": “cisco.advancedservices.com",

            "rd": 894,

            "rt-export": 8940,

            "rt-import": ["8940", "8941","8942", "8943", "8944" ]

        }

}

[root@ncs JSON-Payloads]# curl -X POST -v -T customer-vrf-api-create-serviceonly.json -H'Content-Type: application/vnd.yang.data+json' -u admin:admin http://192.168.81.151:8080/api/running/ncs:services

* About to connect() to 192.168.81.151 port 8080 (#0)

*   Trying 192.168.81.151...

* Connected to 192.168.81.151 (192.168.81.151) port 8080 (#0)

* Server auth using Basic with user 'admin'

> POST /api/running/ncs:services HTTP/1.1

> Authorization: Basic YWRtaW46YWRtaW4=

> User-Agent: curl/7.29.0

> Host: 192.168.81.151:8080

> Accept: */*

> Content-Type: application/vnd.yang.data+json

> Content-Length: 349

> Expect: 100-continue

>

< HTTP/1.1 100 Continue

< Server:

< Allow: GET, POST, OPTIONS, HEAD

< Content-Length: 0

* We are completely uploaded and fine

< HTTP/1.1 201 Created

< Server:

< Location: http://192.168.81.151:8080/api/running/services/enterpriseOnboard:customer-vrf/894,WALNUTCRASR-01

< Date: Wed, 11 May 2016 08:27:56 GMT

< Allow: GET, POST, OPTIONS, HEAD

< Last-Modified: Wed, 11 May 2016 08:27:56 GMT

< Cache-Control: private, no-cache, must-revalidate, proxy-revalidate

< Etag: 1462-955276-440601@ncs-slave

< Content-Length: 0

< Content-Type: text/html

< Pragma: no-cache

<

* Connection #0 to host 192.168.81.151 left intact

[root@ncs JSON-Payloads]#

From NCS User Guide Documentation: If the POST method succeeds, a "201 Created"Status-Line is returned and there is no response message body. Also, a "Location" header identifying the child resource that was created is present in the response.

[root@ncs JSON-Payloads]# curl  -u admin:admin http://192.168.81.151:8080/api/running/services/customer-vrf/894,WALNUTCRASR-01 -X GET -H'Content-Type: application/vnd.yang.operation+json'

<customer-vrf xmlns="http://com/vzw/mpn/enterpriseOnboard" xmlns:y="http://tail-f.com/ns/rest"  xmlns:enterpriseOnboard="http://com/vzw/mpn/enterpriseOnboard"  xmlns:ncs="http://tail-f.com/ns/ncs">

  <customer-id>894</customer-id>

  <device>WALNUTCRASR-01</device>

  <request-id>SLRollTest999</request-id>

  <customer-name>cisco.advancedservices.com</customer-name>

  <rd>894</rd>

  <rt-export>8940</rt-export>

  <rt-import>8940</rt-import>

  <rt-import>8941</rt-import>

  <rt-import>8942</rt-import>

  <rt-import>8943</rt-import>

  <rt-import>8944</rt-import>

  <y:operations>

    <check-sync>/api/running/services/enterpriseOnboard:customer-vrf/894,WALNUTCRASR-01/_operations/check-sync</check-sync>

    <deep-check-sync>/api/running/services/enterpriseOnboard:customer-vrf/894,WALNUTCRASR-01/_operations/deep-check-sync</deep-check-sync>

    <re-deploy>/api/running/services/enterpriseOnboard:customer-vrf/894,WALNUTCRASR-01/_operations/re-deploy</re-deploy>

    <get-modifications>/api/running/services/enterpriseOnboard:customer-vrf/894,WALNUTCRASR-01/_operations/get-modifications</get-modifications>

    <un-deploy>/api/running/services/enterpriseOnboard:customer-vrf/894,WALNUTCRASR-01/_operations/un-deploy</un-deploy>

  </y:operations>

</customer-vrf>

[previousqna]

The service APIs are auto-generated from the respective service model. So don’t think we want to customise the auto-generation on a per model (service-model) basis.

Is doing a POST and then a GET from your portal/app layer not a viable option for your specific use-case?

[previousqna]

most of which get invoked using API/Action layer through which we fine-grain and control the response message content text at a per service level basis.

Restful endpoints invoking all our services are customer's OSS/BSS systems which is consistent with their way of invocation of our services using pre-defined request payload inputs and also expect a predefined response message to progress further in their workflows.

Unfortunately, few flavors of our services do not have API/Action layers and involves only RFS Service-points and hence our response message output dithers from standardized format.  Integration with the external system may be seamless if we have an opportunity to customize per service level as an alternative to POST and GET.

Any ideas from this team on this would be highly appreciated!!

[previousqna]

Thank you for the context about auto-generation of service APIs.  Our Use cases involve various flavors of services most of which get invoked using API/Action layer through which we fine-grain and control the response message content text at a per service level basis.

Restful endpoints invoking all our services are customer's OSS/BSS systems which is consistent with their way of invocation of our services using pre-defined request payload inputs and also expect a predefined response message to progress further in their workflows.

Unfortunately, few flavors of our services do not have API/Action layers and involves only RFS Service-points and hence our response message output dithers from standardized format.  Integration with the external system may be seamless if we have an opportunity to customize per service level as an alternative to POST and GET.

Any ideas from this team on this would be highly appreciated!!

Response message body for REST APIs

[previousqna]

A common technique to provide custom output params is to model an action, model your output params as you like Than have that action call your service.

The northbound REST can then use your action.

[previousqna · Accepted solution]

The scenario you described seems to be a good application of using proxy.

Not perfect, but no need to modify external systems or NSO.

[previousqna]

Do you have an example on how to use a proxy to intercept NSO response and inject contents to response message body?

[previousqna]

I know mulesoft can do these things…the problem is that you would need to support and maintain it.

[previousqna]

Most REST-based toolkits are flexible on the expected return payload on POST, PUT, PATCH, etc. Which toolkit/product is in use here on the client side?

[previousqna]

OSS gateway is based on mulesoft software, you can check it out at:

https://cisco.jiveon.com/docs/DOC-264015