The Rest URL I'm using is "http://geocode.arcgis.com/arcgis/rest/services/World/GeocodeServer/geocodeAddresses?addresses=%7B"records":%5B%7B"attributes":%7B"OBJECTID":1,"SingleLine":"27488 Stanford Ave, Bowden, North Dakota"%7D%7D%5D%7D&sourceCountry=USA&f=pjson&token=<myToken>". It works perfect in browser and Postman. However while I tried it in Java code, it always give me HTTP 400 code, without any additional information. I've checked request HTTP headers and compared, I don't see anything wrong in Java.
Does anybody used this Api in Java and has some idea about it?
I don't have a solution to offer. However, I did want to let you know that I've started seeing a 400 error reported back when calling the ESRI API. I can't even get it to work in my browser. This error just started happening sometime on June 27 or 28. We normally see usage logged on the graph on the ESRI dashboard almost every day (except the weekends) and I'm not seeing any usage logged for Friday the 28th, Monday 7/1, or Today 7/2. So, this has me wondering if there is a problem with the REST API on the ESRI side of things. Here's an example query that is not working for us:
And here's the error response:
Error occurred while processing request
Type: Exception Report
I'm posting here as I don't think we have any tech support since we are on the "pay as you go" plan.
Please let me know if you find a solution to this.
I just figured out that in our case (in C#) I needed to call Uri.EscapeDataString(jsonRequestString); on our JSON addresses object so that the square bracket characters ( [ and ] ) would be Uri data encoded. It has been working fine for a very long time without doing this, so something must have changed on the ESRI side a few days ago that has started requiring us to put the JSON in the escaped format.
Hope this helps,
Thank you Brandon! Yes so I finally figured that we failed the api call also because of encoding issue. We have to manually encode the double quote sign \" to '%22', Java won't do this for us while Postman and Browser do. That's similar to your scenario of bracket characters. It's working now. Cheers
Hi Brandon and Lei,
I checked with the geocoding team and found that the world geocoding service was updated to ArcGIS Server 10.7 in late June and because of security improvements, non-encoded special characters that may have worked before are no longer supported. We apologize for any trouble that this caused to your workflows and will make an effort to provide better preemptive messaging when such changes are put in place in the future.