We use Mapquest's directions API in order to obtain optimized routes. It has been found today, although this may have been going on longer, that our application to obtain these optimized routes no longer works. Our GET requests have been working for years, and nothing has changed in the way they are formatted. And yet the Mapquest API is returning the following error message whenever we send a GET request:
Illegal argument from request: Error parsing JSON provided by HTTP Request.
Here is an example of a standard GET request that we are sending:
https://www.mapquestapi.com/directions/v2/optimizedroute?key=KEY&json={locations:[{latLng:{lat:39.739236,lng:-104.990251}},{latLng:{lat:29.229902,lng:-96.273558}},{latLng:{lat:44.976497,lng:-93.253857}}],options:{doReverseGeocode:false,narrativeType:none}}
Notice how we are using latitude and longitude points, not addresses. We are having a hard time confirming that this is the correct formatting, because Mapquest's documentation seemingly doesn't mention it, but this formatting was devised in some way, and again, it has been working for years.
Our API key is working, because we can plug it into Mapquest's example GET request from their documentation and the request works:
https://www.mapquestapi.com/directions/v2/optimizedroute?key=KEY&json={"locations":["Denver,CO","Westminster,CO","Boulder,CO"]}
We tried various formats using double quotes as tests, and while some formats produced results, the route order was absolutely not correct. Our guess is that adding the quotes allowed the request to be processed, but the latitudes and longitudes were not interpreted as latitudes and longitudes. Can someone shed some light on what is happening? Thanks in advance.
Related
I am submitting a request for data from the Binanance API as follows:
https://api.bscscan.com/api
?module=logs
&action=getLogs
&fromblock=24726622
&toBlock=24726632
&address=0x94084b7a8d80b2c3cc0dccd87cb6ae3cc67d364d
&topic0=0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
&apikey=JRYDR6FBWRKY5C8NMZJKFB8GEP1QHFQJQT
However, I can't get any data from this URL. I have double-checked, and I know that the parameters are correct.
Here is an example of using Binanace's API, which works well:
https://api.bscscan.com/api
?module=logs
&action=getLogs
&fromBlock=4993830
&toBlock=4993832
&address=0xe561479bebee0e606c19bb1973fc4761613e3c42
&topic0=0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
&apikey=YourApiKeyToken
Why is that working but mine not working?
I would highly suggest using Postman, which you can use to quickly test requests. I ran your request, with api-key, through Postman and was able to get a 200 response with data. See this screenshot.
Please note I blanked out the api key value. I suggest you do the same in your post unless its fake.
I had to remove the line breaks in the code you pasted. Could this possibly be the issue?
What should be done if an invalid uri is provided when calling a REST Web API (asp.net mvc)? I'm getting
HTTP Error 404.4 - Not Found
The resource you are looking for does not have a handler associated with it.
When I provide an invalid controller, I get the following:
No HTTP resource was found that matches the request URI
'http://localhost:51929/api/usera'.
No type was found that matches the controller named 'usera'.
I thought 1) was the default and ok, but I've been asked to return a custom html page for both of the above and some others errors but it doesn't feel right to return a web page when dealing with an Web API?
1) Is this common practise?
2) Is there a best practice/standard?
Is there a best practice/standard?
One of the important points in HTTP is that the meta data of the response gives general purpose components the hints to support a coarse understanding of what is going on.
One significant piece of meta data is the response code, which communicates when the response body contains a representation of a resource, and when instead it contains a representation of "an explanation of the error situation".
Does it have to be a "web page"? No, of course not. Instead it could be text/plain, or application/problem+json, or any other representation that you would expect a general purpose client to be able to interpret.
The design of the message should be motivated by its use case, which is to say it is a document intended to be read by a human being trying to figure out what has gone wrong (we don't expect general purpose components to understand how to automatically fix a bad URL; instead, we describe the problem for a person, who will sort it out).
I am using the REST version of the Here Maps API. It seems that if I provide a destination location (latitude, longitude) that cannot be routed the API is returning a HTTP Error of 400 (Bad Request).
I was under the impression I would get a 200 response code but no data would be returned.
For example if I send a request to the API with New York as the source and Paris, France as the destination the API returns a 400 bad request.
The response codes of RESTful APIs are determined by the API developers. From what you are saying it seems that Here Maps does not know how to route someone over the Atlantic Ocean and is telling you that by returning a 400 Bad Request response instead of providing a 200 response. Http Status Code Explanations
You'll want to dig into the api documentation, perhaps the API is expecting two points that can be routed by land and you can supply a way to indicate that by-air and/or by-sea routes are okay also.
Alternatively, you will need check the response status from the Here Maps API first on your program before you attempt to consume it as a 200 status and if you receive a 400 status then you can communicate that there was an error to your end user which you could inform them of the reasons why a particular request might fail. Such a source and destination on continents not linked by a land mass.
(This reminds me of how Google Maps used to provide driving directions which would tell you to kayak across oceans, not sure if still does that but illustrates a way to resolve a by-land route that cannot be taken only by land.)
this might be a stupid question but I was unable to find a solution, also no luck with search.
My Node-Red flow gets triggered by a HTTP Input because I want to create a REST Webservice. It works fine so far but I wonder how to verify the content someone send to me.
As I see right now, I can pass any kind of content. There is no verification if the content matches to the content I want as input.
If I set content-type to application/json, it only accepts json data. That's great but I also want to ensure, users can post only a specific json string.
If someone sends data I'm unable to proceed (not the json object I expected), I want to send HTTP 400 as response.
I'm pretty new to Node-Red and also to json. I'm more an old-school programmer using classic webservices and soap. What I'm missing is some kind of WSDL (not sure if it exists when using REST) and some kind of payload validation.
It would be great if someone can point me the way to go.
Best regards
Patrick
There are some nodes available for doing schema validation on JSON objects.
For example, node-red-contrib-json-schema-validator - which uses ajv as the validation engine under the covers. Unfortunately this node doesn't come with much in the way of help. Essentially it lets you provide your schema and if a message fails to validate, it logs an error which can be handled with a Catch node if you want.
I found the issue. It was too bad.
I just forgotten to set HTTP Header content-type to application/json.
node-red-contrib-json-schema-validator works like a charm if content type is set corret
Since few days, I'm getting an error while requesting ways with the tag 'natural' using Overpass-Turbo.
Here's an example of my requests: http://overpass-turbo.eu/s/fEL
When I execute the request, I'm getting an ajax error: 'Request rejected. (e.g. server not found, request blocked by browser addon, request redirected, internal server errors, etc.)'.
This kind of request used to work very well before. The same request on nodes or relations work, it's only happening with ways tagged 'natural' (and maybe other tags). The error is the same using the webapp Overpass-Turbo.eu or requesting other servers such as http://overpass-api.de/api/interpreter, http://overpass.osm.rambler.ru/cgi/interpreter or http://api.openstreetmap.fr/oapi/interpreter.
I don't know if there are internal issues in Overpass servers or OpenStreetMap database, or if overpass language has been modified, so if somebody has any further information, I would be interested to know it.
This was caused by a recent regression, which has already been fixed. Please see this post for details. Your query should be running fine by now.