After successfully polling an API nine times, this error sprang up. What is it attempting to communicate? Why does it come up after so many good polls? What concrete steps should I take to resolve this?
Thanks for addressing these questions! :)
The argument you are passing to Jason.decode is not valid JSON. In this case it's most likely the response body you got back from the API endpoint. It's likely a string of plain text or HTML, such as:
Internal Server Error
You will need to share your code in order for someone to provide a version of the code that can handle all of the responses you are getting from the API.
Related
I have added headers and token but still having insufficient_scope error by posting json through postman
You must share the details of request to get help. But let me also try to help you out blindly.
I had face the same issue in past and make it possible to resolve the issue by some simple attempts.
Please make sure that your token is correct, its not expired, and if your token is well authorized to make request and get access of the demanding resources from the calling API.
Also make sure that if you have need to add bearer in the start of your token.
Hope it can solve your related issue. Thank You!
Also, check your request method. (I just spent a good 30 minutes trying to figure out why I was failing.) If you have only the listings_r scope, then you can only GET. You must have listings_w to POST. (My problem was copy/pasting several lines of cURL code, and I assume someone else reading this may have done the same.)
I am writing a web service in node, and testing it with Postman. I spent a long timing looking for an error. When I finally found it, it turned out to be a simple error formatting the response body, which is json.
If I leave off the final brace in the response body, Postman waits for two minutes, and then reports that it received everything, just fine.
If I leave off the closing quote in the last value in the json, Postman says the server didn't respond, perhaps I should check my security certificates.
I would much rather Postman said "Hey, Buddy, you left off a quote!"
If there some validation service I can talk to? Or a plugin in Postman?
Here there are some validation javascript libraries, you can use:
Validator provides a declarative way of validating javascript objects.
Express-validator acts as an express.js middleware for node-validator.
Meanwhile, Postman got API testing and Collection Runner that can help you through this; which you can write some pre-request script as well as test script for each request.
Also, they got Newman which is a command-line collection runner. It allows you to effortlessly run and test a Postman collection directly from the command-line. It is built with extensibility in mind so that you can easily integrate it with your continuous integration servers and build systems.
I found that Paw worked (https://paw.cloud/). And so far I haven't paid for it.
Where Postman said "check your security certificates," Paw said "we were expecting 376 bytes but you only sent us 312."
Cuts down my time solving the problem a lot!
I use Fiddler for this. It is very good at identifying (with an error message that pops up) problems and bad implementations of the HTTP protocol. Browse the web with it running, and within a few minutes you'll undoubtedly hit a poorly implemented server.
Postman won't be able to handle these cases since it's insulated from poor behavior by the browser's framework.
That's not your problem though.
When I finally found it, it turned out to be a simple error formatting the response body, which is json.
That has absolutely nothing to do with HTTP. HTTP doesn't know or care what your request/response bodies are.
The problem you face is that your API endpoint could be returning whatever it wants. You need a custom solution to your problem, as there is no standard API server in this case.
Most folks will run unit tests that hit common endpoints of your service to ensure they're alive and well.
I should also point out that it should be all but impossible for you to break the JSON response if you're doing it correctly. Sounds like you're serializing JSON manually... never do that, we have JSON serializers for this purpose. Send in an object and let it worry about building the JSON output for you. Otherwise, you'll waste a lot of time on problems like these.
I'm trying to build a logic app that inserts data into a Sql database. The data is coming from s Stream Analytics job, outputting it on a Service Bus topic, consumed in Logic Apps in Service Bus trigger.
To populate the properties of the row inserted (lets say it only has one column 'Name'), I've found that this should work using following syntax:
"body": {
"Name": "#{json(decodeBase64(triggerBody()['ContentData'])).Name}"
},
Provided the message body contains a 'Name' property.
However I get following error message when running this:
{"code":"InvalidTemplate","message":"Unable to process template language expressions in action 'Insert_row' inputs at line '1' and column '2017': 'The template language function 'json' parameter is not valid. The provided value '#\u0006string\b3http://schemas.microsoft.com/2003/10/Serialization/��{\"time\":\"2016-05-25T10:29:17.4953250Z\",\"Name\":\"Y-Axis\",\"Value\":81.0,\"Date\":\"2016-05-25T10:29:17.4953250\",\"EventProcessedUtcTime\":\"2016-05-25T10:29:17.5525449Z\",\"PartitionId\":2,\"EventEnqueuedUtcTime\":\"2016-05-25T10:29:17.2220000Z\"}\u0001' cannot be parsed: 'Unexpected character encountered while parsing value: #. Path '', line 0, position 0.'. Please see https://aka.ms/logicexpressions#json for usage details.'."}
So it seems like that the content is enclosed in another envelope that is preventing json parsing to work.
1) Any simple way how to get around this?
2) Isn't such an integration all within Microsoft Stack just supposed to work without this mocking around?
Thanks,
Stefan
with the limited string functions available in he workflow definition language I had to use a long winded way for removing the additional strings
#{json(substring(replace(decodeBase64(triggerBody()['ContentData']),'#string3http://schemas.microsoft.com/2003/10/Serialization/��', ''),0,sub(length(replace(decodeBase64(triggerBody()['ContentData']),'#string3http://schemas.microsoft.com/2003/10/Serialization/��', '')),1))).fieldname}
is there a better way to do this
Thanks for reporting this, you're right it should simply work. There is a known issue where ASA ServiceBus output JSON is being wrapped in a XML header. It will be addressed in a near future but can't specify a particular date. Could you please workaround it (maybe using substring/replace) until then ?
cheers,
Chetan
Sorry for the delay in getting back, this issue is now fixed. Its exposed under a new compatibility level (1.1) to avoid breaking existing solutions. Please use this URL to configure your job with compat level 1.1 and give it a try.
cheers!
I have a webservice method that if I call directly via url GET returns XML without issue.
However, POST to that same url with Content-Type Json, it fails.
I think I can figure out the issue (I'm guessing it's an encoding or bad character somewhere in there) but I don't know how to debug the problem.
If I set a breakpoint in the webservice, it runs to completion. The failure appears to be happening AFTER the method returns, but BEFORE the json is returned to the caller.
How can I get in between to trace the error?
Please let me know if I can provide more context to help, but I really just need to know how to get in there.
EDIT:
The web service is configured to receive POST and return JSON and in fact DOES correctly return JSON in some cases. However, there are certain calls that are failing, so I need a way to trace this or debug it somehow and figure out why some calls are not working.
The web service is likely not configured to receive POST requests, especially if you are receiving a 405 Method Not Allowed response status.
Although I didn't find a way to debug or intercept the request to find the exact answer, it turns out the problem was the size of the content being returned by the webservice. Following this answer: ASP.NET WebMethod with jQuery json, is there a size limit?
and increasing the json limit fixed the issue!
Is there a way I could have trapped this to find the error without just guessing it was a size limit?
What is the best practice with regard to sending error responses in a JSON web service? I have seen it done several ways and wanted to know whether there were any agreed-upon standards or best practices among the choices.
I've seen it done where the response includes indication of success or failure as well as the data to be returned or a suitable error message, e.g.
[{'success':true, 'data':{...}]
[{'success':false, 'data':{'message':'error'}]
But I've also seen examples where the JSON object only includes data, and the service uses the normal HTTP error codes to indicate a problem (403, 404, 500, etc). (This is how the Twitter API does it.)
Is there a "right" way to do this, or is it just a matter of style? Is the latter method more "RESTful?"
In a "RESTful" approach, the primary error response is indicated by an appropriate status code (4xx/5xx).
Your message should provide addtional, application-specific hints on how to recover from the error. This may include human-readable representations of the error that has occured or some kind of more technical indicator (i.e. providing an Exception class name).
For being generic, keep to a fix syntax for your error messages. This allows you to introduce new error messages withour breaking the clients.
Use the appropriate HTTP codes and put what you now call "data" as the body of the response. This is the only correcty RESTful way to make the API users aware of an error.
Just doing this will not make your API RESTful, but not doing it will surely make your API non RESTful.
An example of well-used HTTP status codes for errors is in the Dropbox v1 API reference, have a look at the "Errors" sections under each method, they explain which error codes you should expect and what is the associated meaning in that particular method.