json conversion issue in wso2 API Manager - json

We are trying to use wso2 api manager to access some of our RESTful services.
The rest services expect a json payload. When json request is sent to api manager it converts the json request to xml and again while forwarding to the actual endpoint it converts to json back.
The resulting json is not matching exactly the original request in one of our cases.
For instance if the rquest contains an array of elements and if only one element is passed in the array then when api manager forwards the request to the endpoint the array characters ([,]) are removed.
eg.
our original request was
{
"entities": [
{
"name":"KK71CP20000523A1",
"descr":"VaS",
"mnf":"BCT",
"mdlyr":"2012"
}
]
}
the request sent by api manager was
{
"entities":
{
"name":"KK71CP20000523A1",
"descr":"VaS",
"mnf":"BCT",
"mdlyr":"2012"
}
}
The array wrapping is removed under entities element.
When the number of elements is more than one then the array characters are retained.
We faced the same issue in ESB as well previously. But we worked around the issue by extending the default JSONMessageFormatter and using the seriliazeAsArray method available in the jettison library.
But we dont want to do this customization in API Manager.
Is there a better way of fixing this issue? Any patch available from wso2 to fix this?

All carbon products comes with same message builders and formatters, for your case can you check with JSONStreambuilder and formatter.
Look at this reference,

Related

Can the Azure Storage REST API send the response in JSON format?

I am developing a library for working with various types of cloud based queue services.
One of those services is the Azure Queue Storage REST API.
For the Amazon SQS service I can send an Accept: application/json header and the response is in JSON format.
Since JSON is a format that is supported by many APIs and XML is not fun to work with, I would prefer the Azure Storage REST API to also return a response in JSON format.
I have tried to set the Accept: application/json header to no avail. The responses are all in XML format with Content-Type: application/xml, which is obviously not what I was asking for.
Currently all code is in C with dependencies on a couple of libraries, including cURL and jansson, although for this question that doesn't really matter. It's just that I would like the library to be as simple and lightweight as possible.
I have a hard time digging through all kinds of documentation. Most topics I can find are about sending JSON within a message. But that's not what I'm going for.
Is it even possible to receive the actual responses in JSON? I would really like to drop my libxml2 dependency.
As pointed by #Tom Because the documentation is stating that it only return XML, I would personally write an azure function who becomes an adaptor which basically takes your request, sends it to azure queue storage, retrieves the xml response and then converts the xml response to json and return the json to the caller (which will be your C code).
A sample python code to convert xml to json is shown below:
import xmltodict
import json
text = ''
xpars = xmltodict.parse(text)
json = json.dumps(xpars)
print(json)
A sample xml message
text = '<QueueMessagesList>
<QueueMessage>
<MessageId>string-message-id</MessageId>
<InsertionTime>insertion-time</InsertionTime>
<ExpirationTime>expiration-time</ExpirationTime>
<PopReceipt>opaque-string-receipt-data</PopReceipt>
<TimeNextVisible>time-next-visible</TimeNextVisible>
<DequeueCount>integer</DequeueCount>
<MessageText>message-body</MessageText>
</QueueMessage>
</QueueMessagesList>'
And the response will be :
{
"QueueMessagesList": {
"QueueMessage": {
"MessageId": "string-message-id",
"InsertionTime": "insertion-time",
"ExpirationTime": "expiration-time",
"PopReceipt": "opaque-string-receipt-data",
"TimeNextVisible": "time-next-visible",
"DequeueCount": "integer",
"MessageText": "message-body"
}
}
}
Please Note: This whole thing can also be done using a Logic App in azure.
I have only shown the XML to JSON converter part here, but it is really straightforward to write an HTTP Trigger Azure Function to do the same. Or you can even write this converter into your C code as well.
Hope this helps you in moving on with your library development.

WSO2 returning string as infinity number

We are using WSO2 as our API manager to communicate with our backend (nodeJS) services. We are seeing a strange issue with one endpoint where we are requesting a product JSON and are getting a JSON parsing error because of an Infinity number. The original data contains a string however which is "3E10266". When we request the product JSON from Mongo directly from the service we get the correct string back:
{
"_id": 800285,
"SupplierReferenceDescription": "3E10266",
"SupplierReferenceNumber": "3E10266",
}
However requesting this through WSO I get the following:
{
"_id":800285,
"SupplierReferenceDescription":3E+10266,
"SupplierReferenceNumber":3E+10266
}
Which cannot be parsed by our frontend service. It looks like WSO2 is doing some translations on the JSON, can I disable this behaviour? I have found an issue that looks like mine but no clear solution is given: json conversion issue in wso2 API Manager

Spring RESTful service returning JSON from another service

I have been creating Spring RESTful services for a while and typically I am building my own services so I create domain objects and populate them and the framework takes care of the conversion to JSON.
I have a situation now where I simply need my service to act as a pass through to another system's service that is already RESTful and returns JSON.
URL https://:/service/serviceInfo
Method GET
HTTP Content Type Produces: application/json
I simply want to wrap this call (I will apply some security checks on the service) and pass that JSON returned straight back to my service without mapping it back to Java objects, only to return as JSON to the client. Is there a simple way to do this, with minimal code?
Thanks in advance.
Can you see if this works for you?
#RequestMapping("/child")
public String testMethod(#RequestParam String param) {
return new RestTemplate().exchange("https://api.twitter.com/1/statuses/user_timeline.json", HttpMethod.GET, null, String.class).getBody();
}
You just replace the url for your own. I can also guide you to using the RestTemplate with POST or DELETE requests etc. if you need. Also adding parameters or headers if you need. I've used it extensively in some projects.

Why my wso2 esb api return only the first property of the original json?

I'm using wso2 esb 4.0.3.
I used cxf to create a jaxrs api. The first resource is simple. I use SOAP-UI to issue an HTTP GET to this resource, and it returns a json string with the data I expected. Like:
{"id":"some id", "name": "some name", "when":"some time".......}
I created an API in wso2 esb. A resource is configured to call the backend resource mentioned above. When I call this resource using SOAP-UI, I get a json string, but with only the first property of the data. Like:
{"id":"some id"}
What is causing this problem, and how can I fix this?

WCF Data Service - JSON response has extra "results" section

Using the WCF Data Services Toolkit, or the other ways to support the $format param such as JSONPSupportInspectorAttribute I am getting some json responses that are a little odd to me.
Why does my json look like:
{
"d" : {
"results": [
{
"__metadata": {
When the json from OData.org $format is as follows:
{
"d" : [
{
"__metadata": {
Why does mine have an extra "results" sub section?
My data service is just built directly onto my entity framework model. Do I have to use a specific context template for this to go away?
This is versioning. In V2 we added the server driven paging and inline count features which need to store additional metadata on the feed. But since the feed in V1 was just a JSON array, there was no place to put such metadata.
So in V2 all feeds in responses are wrapped in "results" wrapper. That is the feed is a JSON object which has a property called "results" which has the array. There might be additional properties on the feed object (next link, count, ...).
The versioning of the payload is based on the minimum version required by any feature in that payload. So if your service is using something which requires payload of version higher than V1, the entire payload will be written using that higher version.
You can see this even on the odata.org service - try this:
http://services.odata.org/OData/OData.svc/Products?$inlinecount=allpages&$format=json
The response will be V2 and will use the results wrapper.