Our API has a number of endpoints configured as siblings under the same URL space but each potentially served by different back-end systems. Our API is also noun-based, such that the name of the endpoint generally refers to the resource being accessed. For example, a user would POST to /api/create/v1/file to upload a document, then POST to /api/create/v1/conversion to convert that document to a PDF (passing the uploaded file's ID in the body of the conversion request). The file service and the conversion service are separate back-end applications, so we must configure separate endpoints for them.
We've run into a problem making requests to those endpoints with additional path elements, such as a GET to /api/create/v1/file/5678 to get the metadata for file ID 5678. When we configure the file endpoint, our natural inclination is to map the Request Path of "/api/create/v1/file" to and Endpoint Path of "/fileapi/api/create/v1/file". What we've found, however, is that a request to /api/.../file/5678 turns into /fileapi/api/...file5678 (note the missing slash between "file" and "5678"), which our application doesn't like. We have solved that problem by adding a trailing slash to the Endpoint Path ("/fileapi/api/create/v1/file/"), but this results in a request to /api.../file becoming /fileapi/api.../file/ (with a trailing slash). We are currently working around that issue in our application by equating .../file/ with .../file, but we would prefer not to have to do that.
Is there a way to preserve the slash for requests with additional path elements without also including the slash for requests that are just the endpoint itself?
Kevin -
Thank you for your question, the best way to handle this currently is to have two separate endpoints. One for incoming request path of '/api/create/v1/file' which would point to your back end target of '/api/create/v1/file' and another that is incoming as '/api/create/v1/file/' and back end target of '/api/create/v1/file/'. This will guarantee that calls have additional elements after 'file' arrive with the slash between them, while allowing traffic to '../file' to come through with no trailing slash.
Please let us know if you have any further questions.
Our API has a number of endpoints configured as siblings under the same URL space but each potentially served by different back-end systems. Our API is also noun-based, such that the name of the endpoint generally refers to the resource being accessed. For example, a user would POST to /api/create/v1/file to upload a document, then POST to /api/create/v1/conversion to convert that document to a PDF (passing the uploaded file's ID in the body of the conversion request). The file service and the conversion service are separate back-end applications, so we must configure separate endpoints for them.
We've run into a problem making requests to those endpoints with additional path elements, such as a GET to /api/create/v1/file/5678 to get the metadata for file ID 5678. When we configure the file endpoint, our natural inclination is to map the Request Path of "/api/create/v1/file" to and Endpoint Path of "/fileapi/api/create/v1/file". What we've found, however, is that a request to /api/.../file/5678 turns into /fileapi/api/...file5678 (note the missing slash between "file" and "5678"), which our application doesn't like. We have solved that problem by adding a trailing slash to the Endpoint Path ("/fileapi/api/create/v1/file/"), but this results in a request to /api.../file becoming /fileapi/api.../file/ (with a trailing slash). We are currently working around that issue in our application by equating .../file/ with .../file, but we would prefer not to have to do that.
Is there a way to preserve the slash for requests with additional path elements without also including the slash for requests that are just the endpoint itself?
Message edited by Kevin Calcagno 2 years ago
Scott – 2 years ago
Kevin - Thank you for your question, the best way to handle this currently is to have two separate endpoints. One for incoming request path of '/api/create/v1/file' which would point to your back end target of '/api/create/v1/file' and another that is incoming as '/api/create/v1/file/' and back end target of '/api/create/v1/file/'. This will guarantee that calls have additional elements after 'file' arrive with the slash between them, while allowing traffic to '../file' to come through with no trailing slash.
Please let us know if you have any further questions.
Best, Scott