I am developing a REST API using dropwizard. The resource can be accessed using https://<host>:port/item/1. As it can be seen there is no URI prefix. If I have to configure a URI prefix what needs to be done. Can it be configured in yaml configuration file?
Thanks!
Yes the URI prefix a.k.a root path can be configured in YAML. You could use the simple server factory configuration. It's simple, add these two lines in your YAML. I've used 'api' as the prefix. You can replace it with the URI prefix you want.
server:
rootPath: '/api/*'
A slightly more elaborate server configuration looks something like this,
server:
adminConnectors:
-
port: 18001
type: http
adminContextPath: /admin
applicationConnectors:
-
port: 18000
type: http
rootPath: /api/*
type: default
You can refer to this example https://github.com/dropwizard/dropwizard/blob/master/dropwizard-example/example.yml for server and other configuration details.
It's also a good idea to go through this if you are just getting started with dropwizard http://www.dropwizard.io/0.9.2/docs/getting-started.html
Related
I created a REST endpoint following this guide: https://quarkus.io/guides/rest-json
Locally I can successfully use swagger UI on <host>/q/swagger-ui which uses <host>/q/openapi as input. So far so good.
However, in production, I use Nginx to forward the requests to <host>/foobar. Thus, the final URLs change to <host>/foobar/q/swagger-ui and <host>/foobar/q/openapi.
nginx.conf snippet where the Quarkus Docker container is running on port 49321:
location /foobar/ {
proxy_pass http://172.17.0.1:49321/;
}
In the application.properties I already added the following line:
quarkus.swagger-ui.urls.direct=/foobar/q/openapi
By doing this, Swagger-UI finds the OpenAPI spec. But the OpenAPI spec contains the wrong URLs because it doesn't know about the /foobar/ URL segment.
How the OpenAPI looks:
---
paths:
/some/url:
get:
tags:
- blabla
responses:
"200":
description: OK
How it needs to look (/foobar/ prepended to path):
---
paths:
/foobar/some/url:
get:
tags:
- blabla
responses:
"200":
description: OK
I already checked available OpenAPI properties on https://quarkus.io/guides/openapi-swaggerui#openapi but they seem to not solve my problem. Any ideas?
I solved it by setting the following in the application.properties:
quarkus.http.root-path=/foobar
and configuring Nginx as follows (nginx.conf):
location /foobar {
proxy_pass http://172.17.0.1:49321/foobar;
}
I have the following configuration of service with route in Kong:
- name: test
host: test-service
port: 80
protocol: http
path: /endpoint/
routes:
- name: test_route
strip_path: true
preserve_host: true
paths:
- /login
I am trying to understand the following behaviour:
when I access http://localhost/login, I will end up with the http://localhost/endpoint in my browser
however, when I try to access http://localhost/login/test/page, nothing will change and I am still in my browser on http://localhost/login/test/page and the upstream server served my request properly
My expectation was that using http://localhost/login/test/page, my browser will have eventually http://localhost/endpoint/test/page. Apparently I misunderstood it.
I understood that in this case, Kong will use the upstream path as /endpoint/test/page, because I have strip_path: true.
However, how it can be changed in case I want to end up with http://localhost/endpoint/test/page in case I will access http://localhost/login/test/page in my browser?
I am trying to get an old project (not made by me) up and running, and I see that the routes are configured in some peculiar format. This is a typical route config:
customer_home:
path: /customer
host: "web.{domain}"
defaults:
_controller: "BackendBundle:Customer:index"
domain: "%domain%"
methods: [get]
options:
expose: true
requirements:
domain: '%domain%'
Now, I grepped the source code and found domain in the config files. It was null by default and by setting it to localhost:8000 I was able to at least load the root without complaints about %domain%. Now it complains about not finding a matching route, which makes sense, as none was configured. What was configured (which I found by doing console debug:router) was a root route for admin.{domain} and web.{domain}. I assume this means that if the domain is myapp.com, there should be routes configured for admin.myapp.com/ and web.myapp.com.
This is a local development setup, running on 127.0.0.1:8000, so I tried adding this to /etc/hosts:
127.0.0.1 web.localhost admin.localhost
I was now hoping that going to web.localhost:8000 would load a route, but none was matched. I still get NotFoundHttpException, but now I no longer understand why ... How can I configure this setup so that I can load the web and admin subdomains on my development machine? Other routes, like /api/1/doc, works fine.
I was not far off. The answer was to simply drop the port portion of what I had entered as the domain setting. So domain: localhost did the trick. The server is by default running on port 8000, no matter the setting, so it was not needed. I can now access web.localhost and admin.localhost (after adding them as host aliases for the loopback device in /etc/hosts).
I'm trying to deploy two API versions to Google Cloud Endpoints but end up facing configuration issues during the deployment.
API definition api-1.yaml looks like this:
swagger: "2.0"
info:
description: "API"
title: "API"
version: "1.0.0"
host: "api.endpoints.GCP_PROJECT.cloud.goog"
basePath: "/v1"
x-google-api-name: v1
x-google-endpoints:
- name: "api.endpoints.GCP_PROJECT.cloud.goog"
target: "IP_ADDRESS"
...
This works just fine if deployed alone. However if api-2.yaml is added:
swagger: "2.0"
info:
description: "API"
title: "API"
version: "2.0.0"
host: "api.endpoints.GCP_PROJECT.cloud.goog"
basePath: "/v2"
x-google-api-name: v2
x-google-endpoints:
- name: "api.endpoints.GCP_PROJECT.cloud.goog"
target: "IP_ADDRESS"
...
This leads to deployment error: OpenAPI spec is invalid. Multiple endpoint entries are defined in the extension \'x-google-endpoints\'. At most one entry is allowed.
Removing x-google-endpoints extension from one yaml file works but it leaves another yaml file as incomplete and thus, not optimal solution.
Could there be and issue with combining/validating yaml files during deployment? Can x-google-endpoints extension be used to define .cloud.goog domain for versioned API's?
There are two ways to do this:
1) version is in the domain name, such as v1-api.endpoints.GCP_PROJECT.cloud.goog.
You define and deploy two services; one for v1 and another for v2. Each has its own IP, proper service name and its own backend. This is most straightforward way and easy approach.
2) version is in the path, such as api.endpoints.GCP_PROJECT.cloud.goog/v1. You can only define and deploy one service. But you have two backends. This is tricky one. You can use x-google-backend extension in the OpenApi spec and deploy one Cloud Endpoint service.
You are using two ESP proxy as: v1_esp -> v1, v2_esp -> v2.
Each proxy has its own IP and you are trying to bind a domain name to two IPs. This is not supported.
My suggestion is to use one ESP as such:
esp -> v1 + v2 by using x-google-backend.
With the following:
In the openApi.yaml
paths:
/v1/path1:
...
x-google-backend:
address: v1_host
# do above for all your path/methods
/v2:
...
x-google-backend:
address: v2_host
# do above for all your path/methods
x-google-endpoints:
- name: "api.endpoints.GCP_PROJECT.cloud.goog"
target: "IP_ADDRESS"
add --enable_backend_routing and --rewrite to remove /v1 and /v2 prefix before sending the request to your backends.
We have not tested such deployment, but you can try it.
Just wondering what I am missing here when trying to create an API with Tyk Dashboard.
My setup is:
Nginx > Apache Tomcat 8 > Java Web Application > (database)
Nginx is already working, redirecting calls to apache tomcat at default port 8080.
Example: tomcat.myserver.com/webapp/get/1
200-OK
I have setup tyk-dashboard and tyk-gateway previously as follows using a custom node port 8011:
Tyk dashboard:
$ sudo /opt/tyk-dashboard/install/setup.sh --listenport=3000 --redishost=localhost --redisport=6379 --mongo=mongodb://127.0.0.1/tyk_analytics --tyk_api_hostname=$HOSTNAME --tyk_node_hostname=http://127.0.0.1 --tyk_node_port=8011 --portal_root=/portal --domain="dashboard.tyk-local.com"
Tyk gateway:
/opt/tyk-gateway/install/setup.sh --dashboard=1 --listenport=8011 --redishost=127.0.0.1 --redisport=6379 --domain=""
/etc/hosts already configured (not really needed):
127.0.0.1 dashboard.tyk-local.com
127.0.0.1 portal.tyk-local.com
Tyk Dashboard configurations (nothing special here):
API name: foo
Listen path: /foo
API slug: foo
Target URL: tomcat.myserver.com/webapp/
What URI I suppose to call? Is there any setup I need to add in Nginx?
myserver.com/foo 502 nginx
myserver.com:8011/foo does not respond
foo.myserver.com 502 nginx
(everything is running under the same server)
SOLVED:
Tyk Gateway configuration was incorrect.
Needed to add --mongo and remove --domain directives at setup.sh :
/opt/tyk-gateway/install/setup.sh --dashboard=1 --listenport=8011 --redishost=localhost --redisport=6379 --mongo=mongodb://127.0.0.1/tyk_analytics
So, calling curl -H "Authorization: null" 127.0.0.1:8011/foo
I get:
{
"error": "Key not authorised"
}
I am not sure about the /foo path. I think that was previously what the /hello path is. But it appears there is a key not authorized issue. If the call is made using the Gateway API, then the secret value may be missing. It is required when making calls to the gateway (except the hello and reload paths)
x-tyk-authorization: <your-secret>
However, since there is a dashboard present, then I would suggest using the Dashboard APIs to create the API definition instead.