I developed a web service that extracts messages from a database and returns an object containing a table and a string, as a json response.
The problem is that I can't extract data from the client application when I consume the web service.
This is the reponse I get when I run the web service
{
"msgTabl":
{
"list":
[
{"contenu":"aid mabroukk","dateEnvoi":"2014-07-30","frommm":"voeuxmsg","id":0,"idu":0,"numExp":50840749},
{"contenu":222222222222,"dateEnvoi":222222,"frommm":222222222222,"id":0,"idu":0,"numExp":2222222},
{"contenu":3333333333,"dateEnvoi":3333333333,"frommm":333333333,"id":0,"idu":0,"numExp":33333333333}
],
"test":"ok"
}
}
I tried to take the json content from my client application, but I couldn't because of the structure of my json reponse. I don't know why this "msgTabl" is shown at the beginning.
You can use
reponse['msgTabl']
in your client application to get the right structure you want
Related
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.
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
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,
I would be wanting a tool which can mock a RESTFul server and it should return the preset JSON data which I have mapped for a particular URL.
For ex: If I call http://ccccc.com/api/users , the mockup tool should return users ( which I have already preset ) in JSON format.
This might be useful when I create client side code with backbone or jquery to get back the models using an ajax call.
Any suggestions for this kind of mockup tool ?
Note: Creating a servlet which reads the incoming GET url and reads the preset JSON from a file and outputting it as JSON string is possible. But I am looking for a tool which will do this for me.
Sinon.js is what you're looking for. In particular the sinon.fakeServer API.
https://github.com/homerquan/kakuen
Mock up RESTful webservices simply by editing text files, e.g.,
GET_#book#123#authors.json ==> GET /book/123/authors
POST_#book#id=123.json ==> POST /book?id=123
For json, a schema-based mockup is supported, e.g., in sample_server/mocks/GET__#search#q=js.json
e.g.,
"#KAKUEN_ITEM(offset)": {
"#KAKUEN_TYPE": "natural",
"#KAKUEN_PARAM": {
"min": 1,
"max": 20
}
}
will be offset:12
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.