A solution for "404 - File or directory not found" when using GeocodeAddresses in ArcGIS Server 10.3.1 was shared with me by a member of the ESRI staff, Dennis Jarrard, I've re-posted the solution on his behalf.
Environment: Windows Server 2008 R2; IIS 7.0; ArcGIS Server 10.3.1
Problem: We have published our address locator file to ArcGIS Server and attempted passing-in addresses to the Geocode Addresses REST endpoint (http://<ServerName>/arcgis/rest/services/<LocatorName>/GeocodeServer/geocodeAddresses?addresses={"records": [.....) for geocoding. We are successful geocoding up to about 10 addresses, but have not been able to geocode a larger amount of addresses.
Solution:
The issue here may be a length limit. Typically length limits are applied through all proxies and endpoints. Even modern browsers can sometimes limit URL length. ArcGIS Server has a length limit, though I do believe it’s a bit longer than what you’ve shared. My guess is that the web adaptor may be imposing a limit (as it works under the constraints of IIS). To test this, you could try sending the request directly to ArcGIS Server (port 6080) instead of through the web adaptor. However, that’s not really a permanent fix.
When sending large amounts of data through a request, or if you need to conceal the parameters of the request, you should use a POST request. In the example you’ve provided, it appears to be a GET request. The difference is that in a GET request, all parameters and values are specified in the URL. This means that the URL can get quite long and unruly. For most query or Find Address Candidates requests, which are short and simple, this is usually just fine. When you start passing many addresses with several fields, you run into length issues. A POST request transmits all of the parameters and values in the body of the request instead of using the URL. Not only does this mean that you can clean up the URL, but it also means that the parameters themselves are not visible to prying eyes. If you send a post request over HTTPS, the body itself is completely encrypted. I’m not sure whether this is important to you, but it’s something to consider.
To send a POST request instead of GET, you can start at the REST endpoint of the service. Go to this endpoint in your browser and fill out the parameters with the information. When ready, click POST instead of GET. If you get different results depending on which one you click, then we likely have our answer. If you’re sending these requests through an application, you’ll need to slightly modify your app so that the request is sent using POST instead.
-K
