Hey I m using openapi version 3.0.3 to add restApi's in Aws gateway. The problem is I have to add a basePath for all my Api's.
The docs says "If the API doesn't contain any basePath variables, the Import API feature checks the server.url string to see if it contains a path beyond "/". If it does, that path is used as the base path".
I tried adding the following basePath in server.url
servers :[
{
"url" : "/foo"
}
]
but the basePath is not getting reflected am I missing something here?
Related
I am implementing a web socket server application using play framework 2.7
I would like to implement a remote configuration where all the application's
configuration should reside in a github.
When i searched for documents to implement it, i found below url,
https://github.com/play-rconf
but accessing configuration from github is not listed.
Is there any better way or document do access the config server from github (like in Spring) ?
You can try play-rconf-http by specifying a URL of your config file:
remote-configuration {
## Provider - HTTP
# ~~~~~
# Retrieves configuration from a simple HTTP server
http {
# URL where is located the configuration file to fetch. You can
# use basic authentication
url = "https://raw.githubusercontent.com/<user>/<repo>/<branch>/<path-to-file>"
url = ${?REMOTECONF_HTTP_URL}
}
}
You can use basic authentication as well.
Look Download single files from GitHub for more info regarding GitHub link.
i uploaded images to google storage bucket and i am no trying to set the CDN using the load balancer to work.
Storage Status :
Bucket Permissions : Storage Object Viewer - Reader assign to allUsers ,
Storage Legacy Bucket Reader assign To allUsers
File Status :
Share Public is set and there is a public link
Load Balancer:
Set to path /creatives/* on the host name
but i always get this msg:
<Error>
<Code>NoSuchKey</Code>
<Message>The specified key does not exist.</Message>
</Error>
what i notice is as soon as i build the path of /creatives/* there is another path build /* direct to the backend service of the auto scale group
am i missing here any settings?
So as i discovered Google CDN + Google http Load balancer works different from other CDN.
with a regular CDN you can direct the origin to you bucket HTTP address and work on the / structure.
for example :
Google CDN Bucket URL:
googleapi.storage.com/my-bucket
Folder structure:
/1/1.jpg
Normal CDN origin will be pointing to googleapi.storage.com/my-bucket
and you will get a new service endpoint for the CDN like:
my-bucket.fastly.cdonservice.com
and this call will work:
my-bucket.fastly.cdonservice.com/1/1.jpg
but on google cloud what you are setting up is a path that is connected to the CDN service that you created on the backend part.
So this is the big difference, lets assume that you created this path rule.
host: www.googlecdnnonexplainedfeautres.com
path: /images/*
service: yourbackendservice (connected to the bucket you want to cache)
so you might assume this should work:
www.googlecdnnonexplainedfeautres.com/images/1/1.jpg.
but NO ..
after digging the logs you will find a 404 on the bucket because google will go and search this path on the bucket:
googleapi.storage.com/my-bucket/images/1/1.jpg.
wait , where did the images came ? i thought its a hook. no google take this as a static website root ( the thing you can check on and off on S3) so here its mandatory.
so how this should work ?
modify the folder structure to be like this :
Google CDN Bucket URL:
googleapi.storage.com/my-bucket
Folder structure:
images/1/1.jpg
and now you are good.
This link should work now :
www.googlecdnnonexplainedfeautres.com/images/1/1.jpg.
so before you commit a bucket to be used as CDN source for google just add another top folder that match with the path you set on the LB.
and of course .. permissions , allUsers , read and etc..
EnjoY!
You can use URL Rewrites to solve this problem.
This may not have existed back in 2017 but there's an option at least as of 2021.
Explanation:
The lb's default behavior is to pass the entire path after the host to Cloud Storage. This may seem incorrect, but it's a sane default (How is the load balancer supposed to know what part of the path you want to include or exclude?).
I was facing the same issue.
I connected mydomain.com/static/* to my cloud storage bucket static-assets.
Upon visiting mydomain.com/static/static-asset.jpg the load balancer would request cloud storage for an object with key static-assets/**static**/static-asset.jpg.
Since the object's actual key is static-assets/static-asset.jpg, this would return a NoSuchKey response.
The fix was the rewrite the path prefix of /static to /.
One way to configure this is through the Cloud Console Load Balancer UI--we can add an advanced path rule to rewrite the prefix.
Please note:
Important: The rewrite is prepended to the path as is. Full path
rewrites are not supported. HTTP(S) Load Balancing only implements
path prefix rewrites. For example, you can rewrite:
host.name/path1/resource1 to host.name/path2/resource1. You cannot
rewrite host.name/path1/resource1 to host.name/path1/resource2.
Read about URL Rewrites here.
I want to create a different base URI for each of the dozen customers of my API so the endpoints are the same but I can filter on customer. I think adding a template parameter to the base URI is the solution but how do I use the baseUriParameter?
I've imported a RAML spec into APIMATIC that has a baseUriParameter.
baseUri: http://{fi}.api.mycompany.com
baseUriParameters:
fi:
type: string
This template parameter gets added to each endpoint as a parameter. Here's an example endpoint.
/users:
get:
This gives an error message.
"Endpoint Users has an unused template parameter named fi."
APIMATIC has a parameter added to the endpoint.
It also means no test cases have been auto-generated.
How do I use the baseUriParameter?
Try importing your RAML API description file again. APIMATIC will use your baseUri and create template parameters now. You can checkout the Server Configuration page to see what parameters in the baseUri were recognized and set the default values for them as well.
Reference documentation for Server Configuration and template parameters in baseUri: https://docs.apimatic.io/api-editor/server-configuration/
Hope this helps!
When using the AWS Api-Gateway service, I'd like to add a "parent" resource without deleting and rebuilding the resource structure. Specifically, I'd like to change this:
resource/name
resource/name
And add a "parent" resource to it (v1) without deleting and remaking the two "resource/name" resources, like this:
/v1
/resource/name
/resource/name
If it requires use of the CLI, what would an example command look like?
UPDATE:
Thanks for the great answer Ka Hou Ieong. Here are some notes on implementing it:
rest-api-id : Put the api id here. You can look it up with this command: aws apigateway get-rest-apis
resource-id : Put the id of the resource you'd like to move here. You can look it up with this command: aws apigateway get-resources --rest-api-id API-ID-HERE
replace : Leave this; it's the operation.
/parentId : Leave this. It refers to the "key" of the value that you'll replace.
<new parent resourceId> : Replace this with the ID of the parent you'd like.
You can create a resource with path part "/v1", then re-parent these resources by using the CLI tool or SDK.
Example cli command to reparent the resource
aws apigateway update-resource \
--rest-api-id rest-api-id \
--resource-id resource-id \
--cli-input-json "{\"patchOperations\" : [
{
\"op\" : \"replace\",
\"path\" : \"/parentId\",
\"value\" : \"<new parent resourceId>\"
}
]}"
Here is the cli tool documentation: http://docs.aws.amazon.com/cli/latest/reference/apigateway/update-resource.html
Here is the API reference: http://docs.aws.amazon.com/apigateway/api-reference/link-relation/resource-update/
Following the spring.io example here: http://spring.io/guides/gs/accessing-data-rest/ for exposing a repository as a rest web service works just fine, but I cannot see how to change the URL of the exposed service. The API documentation is a little vague as to what the annotation parameters mean, perhaps some prior knowledge is assumed.
What I want - A HATEOAS service accessed at http://localhost:8080/api/people for a People repository. I want to achieve this URL using annotations only, not messing with the context root or similar. I tried the following repository annotations:
#RepositoryRestResource(collectionResourceRel = "api/people", path = "people")
#RepositoryRestResource(collectionResourceRel = "people", path = "api/people")
#RepositoryRestResource(collectionResourceRel = "api/people", path = "api/people")
None of these work.
I know I have probably missed the obvious, much appreciate anyone who can point it out.
As of Spring Boot 1.2 you are able to set this property:
spring.data.rest.baseUri=api
Alternatively:
spring.data.rest.base-uri=api
(Spring Boot uses a relaxed binding system)
NOTE: I have found that if you have extended RepositoryRestMvcConfiguration with custom configuration, the property does not take effect. For more information see:
https://github.com/spring-projects/spring-boot/issues/2392
Once the next version of Spring Boot is released (after 1.2.1), the solution will be to extend RepositoryRestMvcBootConfiguration instead.
As of Spring Boot 1.4.3 the code should be :
spring.data.rest.base-path:api
(I think baseUri is deprecated since 1.2.3)
Although I couldn't change the base path of the REST services using the annotation #RepositoryRestResource combined with a CrudRepository, I managed to do it using a JpaRepository and a custom controller with the annotation #RequestMapping.
The repository could be something like:
#Repository
interface PersonRepository : JpaRepository<Person, Long>
And the controller:
#RestController
#RequestMapping("/api/people")
class PersonRestController(private val personRepository: PersonRepository) {
...
On the other hand, you can change the base path of all your REST services modifying it in the application.properties file of your project. Add the lines:
# DATA REST (RepositoryRestConfiguration)
spring.data.rest.base-path = api
Change api with the path you wish you use in your URLs. The first line is a comment and, as so, it's not mandatory, but is useful to mark the nature of the configuration value for future references.
You can find all the common application properties of Spring Boot 2.0.1 in the Appendix A of the documentation.