Does anyone know how to ignore request to paths which do not exist on APIM?
If i run a scanner against APIM it will return 404 for APIs which don't exist. I would like to ignore (not respond with 404) when scans attempt to consume paths which have not corresponding API/Path on APIM.
e.g.
/api/v1/with-backing-service == Return from backing service (200, 401, 404, etc...)
/api/v1/without-backing-service === Terminates (No response)
Don't think that is possible. The HTTP request (basically a TCP request) would reach the server either way and APIM will have to receive it to find out the URL path.
Returning a 404 is the right way to respond for invalid paths. Even if you were to place something like a reverse proxy before APIM, that service would have to read the request to know where it has to route it to and return something (a 404) if it doesn't recognize the path.
If the intention is to protect your APIM endpoint from the public internet, consider placing it inside a VNET if possible.
Related
I am having an issue calling External Transfer Settings API. I tested other APIs and was able to get a response. Below is the URI I used for External Transfers.
https://banno.com/a/transfer-settings/api/v0/institutions/xxxx/xxxxxxx/transfer/settings/external
and the response I got is 'Cannot PUT /a/transfer-settings/api/v0/institutions/xxxx/xxxxx/transfer/settings/external'
1) Which endpoint is the the one that is failing?
The /xxxx/xxxxx/ makes it a bit ambiguous if this is the Institution External Transfer Settings endpoint (PUT /a/transfer-settings/api/v0/institutions/{institutionId}/transfer/settings/external or if it is the User External Transfer Settings endpoint (PUT /a/transfer-settings/api/v0/institutions/{institutionId}/users/{userId}/transfer/settings/external
2) Can you provide the full error response?
The error response will have an HTTP status code (which is helpful), a response body, and a header x-request-id (which is also helpful) to understand what is occurring.
Facing a problem with protocols, please find the below code snippet.
If rquestedUrl starts with https, getResponse.getStatusLine().getStatusCode() is returning 200 whereas if the same rquestedUrl starts with http, getResponse.getStatusLine().getStatusCode() is returning 404.
But if I hit through browser I am able to access the requested file in both cases. Could you please let me know what could be the possible problems. (It is used as a filter before calling Orbeon, this is on the process of implementing WSSO.)
System.setProperty("javax.net.ssl.trustStore", "path_to_JKSFile");
System.setProperty("javax.net.ssl.trustStoreType","JKS");
System.setProperty("javax.net.ssl.trustStorePassword","password");
String rquestedUrl = "http://bigminds.web.mindblow.com/project/project1/views/files/Home.xhtml";
HttpClient client = HttpClients.createDefault();
HttpGet get = new HttpGet(rquestedUrl);
get.addHeader("Cookie", "somevalues");
get.addHeader("Host", "bigminds.mindblow.com:14325");
HttpResponse getResponse = client.execute(get);
It's likely that the endpoint you are hitting does not accept http requests, all requests must be though https. So there isn't anything wrong with your code, it's just not set up to properly integrate with the site you have there. Looking at the code it looks like you may need to have some type of session (ie: need to login) with the webserver to get the data you want.
Say for example I'm try to make a GET Request to www.testjson.com/json, However the response is retrieved from a different domain URL e.g. www.testjson.com/confirmJson.
Does Spring mvc support this, specifically restTemplate.exchange functionality.
I am currently doing this sort of thing, but I am getting an 500 status code (internal server error) and have no way of finding out what exactly is causing the error.
So can RestTemplate actually manage the redirect and provide the necessary JSON response or does it actually wait for the response from the url you provide hence the reason for getting the 500 internal server error?
It is possible to let a RestTemplate automatically follow a redirect.
The server must respond with a Http 3xx and the location header set.
The RestTemplate 'understands' this response and issues a new GET request to the returned location.
This should work with default spring configuration.
See also follow-302-redirect-using-spring-resttemplate
In a JSON-REST service architecture (following these patterns for methods and response codes) we often need to generate a deliberate 404 response - for example, if GET /users/123 is routed to a controller, which is then unable to find a User entity with ID 123, we return a 404 response, which in many cases will include a JSON payload with an error message/code/etc.
Now, when we provide a client for a specific API, we want the client to behave differently under different conditions. For example, if we point the client to the wrong host, we might get a 404 not found from that host - as opposed to the 404 we might get for an invalid User ID if we do reach the service.
In this case, a "404 User ID not found" is not an error, as far as the client is concerned - as opposed to any other "404 Not Found", which should cause the client to throw an exception.
My question is, how do you distinguish between these 404 errors?
Solely based on the response?
By adding a header to indicate a valid response?
Or some other way?
It is OK to return 404 in both cases. As 4xx codes are client relevant codes, it is also OK to return content even if there was an error.
Now, deciding what kind of 404 it was can be decided based on the body of the response. Remember, that the response should carry a mime-type that is compatible with the Accept header the client supplied. So if the client "knows" your specific error-describing format, your server can answer with a more detailed description.
This way both the server can decide whether the client would understand a detailed response with the 404, and the client also understands when it just got a regular 404, or one with a message it can process.
This would be both semantically correct, and compatible with HTTP.
We've got an API running on Nginx, supposed to return JSON objects. This server has a lot of load so we did a lot of performance improvements.
The API recieves an ID from the client. The server has a bunch of files representing these IDs. So if the ID is found as a file, the contents of that file (Which is JSON) will be returned by the backend. If the file does not exists, no backend is called, Nginx simple sends a 404 for that, so we save performance (No backend system has to run).
Now we stumbled upon a problem. Due to old systems we still have to support, we cannot hand out a 404 page for clients as this will cause problems. What I came up with, is to return an empty JSON string instead ({}) with a 'fake' 200 status code. This needs to be a highly performant solution to still be able to handle all the load.
Is this possible to do, and if so, how?
error_page 404 =200 #empty_json;
location #empty_json {
return 200 "{}";
}
Reference:
http://nginx.org/r/error_page
http://nginx.org/r/return
http://nginx.org/r/location
You can always create a file in your document root called e.g. empty.json which only contains an empty object {}
Then in your nginx configuration add this line in your location block
try_files $uri /empty.json;
( read more about try_files )
This will check if the file requested by the client exists and if it does not exist it just shows empty.json instead. This produces a 200 HTTP OK and shows a {} to the requesting client.