mirror of
https://github.com/nsnail/Ocelot.git
synced 2025-06-18 23:28:14 +08:00
Feat/monorepo (#734)
* copied everything from repos back to ocelot repo * added src projects to sln * removed all test projects that have no tests * added all test projects to sln * removed test not on master * merged unit tests * merged acceptance tests * merged integration tests * fixed namepaces * build script creates packages for all projects * updated docs to make sure no references to external repos that we will remove * +semver: breaking
This commit is contained in:
Tom Pallister
@ -33,7 +33,7 @@ All you need to do to hook into your own IdentityServer is add the following to
|
||||
|
||||
You now need to get a token from your IdentityServer and use in subsequent requests to Ocelot's administration API.
|
||||
|
||||
This feature was implemented for `issue 228 <https://github.com/TomPallister/Ocelot/issues/228>`_. It is useful because the IdentityServer authentication
|
||||
This feature was implemented for `issue 228 <https://github.com/ThreeMammals/Ocelot/issues/228>`_. It is useful because the IdentityServer authentication
|
||||
middleware needs the URL of the IdentityServer. If you are using the internal IdentityServer it might not alaways be possible to have the Ocelot URL.
|
||||
|
||||
Internal IdentityServer
|
||||
|
||||
@ -32,7 +32,7 @@ Finally in order to use caching on a route in your ReRoute configuration add thi
|
||||
|
||||
In this example ttl seconds is set to 15 which means the cache will expire after 15 seconds.
|
||||
|
||||
If you look at the example `here <https://github.com/TomPallister/Ocelot/blob/develop/test/Ocelot.ManualTest/Program.cs>`_ you can see how the cache manager
|
||||
If you look at the example `here <https://github.com/ThreeMammals/Ocelot/blob/develop/test/Ocelot.ManualTest/Program.cs>`_ you can see how the cache manager
|
||||
is setup and then passed into the Ocelot AddCacheManager configuration method. You can use any settings supported by
|
||||
the CacheManager package and just pass them in.
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Configuration
|
||||
============
|
||||
|
||||
An example configuration can be found `here <https://github.com/TomPallister/Ocelot/blob/develop/test/Ocelot.ManualTest/ocelot.json>`_.
|
||||
An example configuration can be found `here <https://github.com/ThreeMammals/Ocelot/blob/develop/test/Ocelot.ManualTest/ocelot.json>`_.
|
||||
There are two sections to the configuration. An array of ReRoutes and a GlobalConfiguration.
|
||||
The ReRoutes are the objects that tell Ocelot how to treat an upstream request. The Global
|
||||
configuration is a bit hacky and allows overrides of ReRoute specific settings. It's useful
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Delegating Handlers
|
||||
===================
|
||||
|
||||
Ocelot allows the user to add delegating handlers to the HttpClient transport. This feature was requested `GitHub #208 <https://github.com/TomPallister/Ocelot/issues/208>`_
|
||||
and I decided that it was going to be useful in various ways. Since then we extended it in `GitHub #264 <https://github.com/TomPallister/Ocelot/issues/264>`_.
|
||||
Ocelot allows the user to add delegating handlers to the HttpClient transport. This feature was requested `GitHub #208 <https://github.com/ThreeMammals/Ocelot/issues/208>`_
|
||||
and I decided that it was going to be useful in various ways. Since then we extended it in `GitHub #264 <https://github.com/ThreeMammals/Ocelot/issues/264>`_.
|
||||
|
||||
Usage
|
||||
^^^^^
|
||||
|
||||
@ -1,150 +1,150 @@
|
||||
Headers Transformation
|
||||
======================
|
||||
|
||||
Ocelot allows the user to transform headers pre and post downstream request. At the moment Ocelot only supports find and replace. This feature was requested `GitHub #190 <https://github.com/TomPallister/Ocelot/issues/190>`_ and I decided that it was going to be useful in various ways.
|
||||
|
||||
Add to Request
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
This feature was requestes in `GitHub #313 <https://github.com/ThreeMammals/Ocelot/issues/313>`_.
|
||||
|
||||
If you want to add a header to your upstream request please add the following to a ReRoute in your ocelot.json:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"UpstreamHeaderTransform": {
|
||||
"Uncle": "Bob"
|
||||
}
|
||||
|
||||
In the example above a header with the key Uncle and value Bob would be send to to the upstream service.
|
||||
|
||||
Placeholders are supported too (see below).
|
||||
|
||||
Add to Response
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
This feature was requested in `GitHub #280 <https://github.com/TomPallister/Ocelot/issues/280>`_.
|
||||
|
||||
If you want to add a header to your downstream response please add the following to a ReRoute in ocelot.json..
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Uncle": "Bob"
|
||||
},
|
||||
|
||||
In the example above a header with the key Uncle and value Bob would be returned by Ocelot when requesting the specific ReRoute.
|
||||
|
||||
If you want to return the Butterfly APM trace id then do something like the following..
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"AnyKey": "{TraceId}"
|
||||
},
|
||||
|
||||
Find and Replace
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
In order to transform a header first we specify the header key and then the type of transform we want e.g.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"Test": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
|
||||
The key is "Test" and the value is "http://www.bbc.co.uk/, http://ocelot.com/". The value is saying replace http://www.bbc.co.uk/ with http://ocelot.com/. The syntax is {find}, {replace}. Hopefully pretty simple. There are examples below that explain more.
|
||||
|
||||
Pre Downstream Request
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Add the following to a ReRoute in ocelot.json in order to replace http://www.bbc.co.uk/ with http://ocelot.com/. This header will be changed before the request downstream and will be sent to the downstream server.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"UpstreamHeaderTransform": {
|
||||
"Test": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
},
|
||||
|
||||
Post Downstream Request
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Add the following to a ReRoute in ocelot.json in order to replace http://www.bbc.co.uk/ with http://ocelot.com/. This transformation will take place after Ocelot has received the response from the downstream service.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Test": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
},
|
||||
|
||||
Placeholders
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Ocelot allows placeholders that can be used in header transformation.
|
||||
|
||||
{RemoteIpAddress} - This will find the clients IP address using _httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString() so you will get back some IP.
|
||||
{BaseUrl} - This will use Ocelot's base url e.g. http://localhost:5000 as its value.
|
||||
{DownstreamBaseUrl} - This will use the downstream services base url e.g. http://localhost:5000 as its value. This only works for DownstreamHeaderTransform at the moment.
|
||||
{TraceId} - This will use the Butterfly APM Trace Id. This only works for DownstreamHeaderTransform at the moment.
|
||||
|
||||
Handling 302 Redirects
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
Ocelot will by default automatically follow redirects however if you want to return the location header to the client you might want to change the location to be Ocelot not the downstream service. Ocelot allows this with the following configuration.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
or you could use the BaseUrl placeholder.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "http://localhost:6773, {BaseUrl}"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
finally if you are using a load balancer with Ocelot you will get multiple downstream base urls so the above would not work. In this case you can do the following.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "{DownstreamBaseUrl}, {BaseUrl}"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
X-Forwarded-For
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
An example of using {RemoteIpAddress} placeholder...
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"UpstreamHeaderTransform": {
|
||||
"X-Forwarded-For": "{RemoteIpAddress}"
|
||||
}
|
||||
|
||||
Future
|
||||
^^^^^^
|
||||
|
||||
Ideally this feature would be able to support the fact that a header can have multiple values. At the moment it just assumes one.
|
||||
It would also be nice if it could multi find and replace e.g.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "[{one,one},{two,two}"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
If anyone wants to have a go at this please help yourself!!
|
||||
Headers Transformation
|
||||
======================
|
||||
|
||||
Ocelot allows the user to transform headers pre and post downstream request. At the moment Ocelot only supports find and replace. This feature was requested `GitHub #190 <https://github.com/ThreeMammals/Ocelot/issues/190>`_ and I decided that it was going to be useful in various ways.
|
||||
|
||||
Add to Request
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
This feature was requestes in `GitHub #313 <https://github.com/ThreeMammals/Ocelot/issues/313>`_.
|
||||
|
||||
If you want to add a header to your upstream request please add the following to a ReRoute in your ocelot.json:
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"UpstreamHeaderTransform": {
|
||||
"Uncle": "Bob"
|
||||
}
|
||||
|
||||
In the example above a header with the key Uncle and value Bob would be send to to the upstream service.
|
||||
|
||||
Placeholders are supported too (see below).
|
||||
|
||||
Add to Response
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
This feature was requested in `GitHub #280 <https://github.com/ThreeMammals/Ocelot/issues/280>`_.
|
||||
|
||||
If you want to add a header to your downstream response please add the following to a ReRoute in ocelot.json..
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Uncle": "Bob"
|
||||
},
|
||||
|
||||
In the example above a header with the key Uncle and value Bob would be returned by Ocelot when requesting the specific ReRoute.
|
||||
|
||||
If you want to return the Butterfly APM trace id then do something like the following..
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"AnyKey": "{TraceId}"
|
||||
},
|
||||
|
||||
Find and Replace
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
In order to transform a header first we specify the header key and then the type of transform we want e.g.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"Test": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
|
||||
The key is "Test" and the value is "http://www.bbc.co.uk/, http://ocelot.com/". The value is saying replace http://www.bbc.co.uk/ with http://ocelot.com/. The syntax is {find}, {replace}. Hopefully pretty simple. There are examples below that explain more.
|
||||
|
||||
Pre Downstream Request
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Add the following to a ReRoute in ocelot.json in order to replace http://www.bbc.co.uk/ with http://ocelot.com/. This header will be changed before the request downstream and will be sent to the downstream server.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"UpstreamHeaderTransform": {
|
||||
"Test": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
},
|
||||
|
||||
Post Downstream Request
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Add the following to a ReRoute in ocelot.json in order to replace http://www.bbc.co.uk/ with http://ocelot.com/. This transformation will take place after Ocelot has received the response from the downstream service.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Test": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
},
|
||||
|
||||
Placeholders
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Ocelot allows placeholders that can be used in header transformation.
|
||||
|
||||
{RemoteIpAddress} - This will find the clients IP address using _httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString() so you will get back some IP.
|
||||
{BaseUrl} - This will use Ocelot's base url e.g. http://localhost:5000 as its value.
|
||||
{DownstreamBaseUrl} - This will use the downstream services base url e.g. http://localhost:5000 as its value. This only works for DownstreamHeaderTransform at the moment.
|
||||
{TraceId} - This will use the Butterfly APM Trace Id. This only works for DownstreamHeaderTransform at the moment.
|
||||
|
||||
Handling 302 Redirects
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
Ocelot will by default automatically follow redirects however if you want to return the location header to the client you might want to change the location to be Ocelot not the downstream service. Ocelot allows this with the following configuration.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "http://www.bbc.co.uk/, http://ocelot.com/"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
or you could use the BaseUrl placeholder.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "http://localhost:6773, {BaseUrl}"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
finally if you are using a load balancer with Ocelot you will get multiple downstream base urls so the above would not work. In this case you can do the following.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "{DownstreamBaseUrl}, {BaseUrl}"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
X-Forwarded-For
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
An example of using {RemoteIpAddress} placeholder...
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"UpstreamHeaderTransform": {
|
||||
"X-Forwarded-For": "{RemoteIpAddress}"
|
||||
}
|
||||
|
||||
Future
|
||||
^^^^^^
|
||||
|
||||
Ideally this feature would be able to support the fact that a header can have multiple values. At the moment it just assumes one.
|
||||
It would also be nice if it could multi find and replace e.g.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
"DownstreamHeaderTransform": {
|
||||
"Location": "[{one,one},{two,two}"
|
||||
},
|
||||
"HttpHandlerOptions": {
|
||||
"AllowAutoRedirect": false,
|
||||
},
|
||||
|
||||
If anyone wants to have a go at this please help yourself!!
|
||||
|
||||
@ -1,49 +1,49 @@
|
||||
Raft (EXPERIMENTAL DO NOT USE IN PRODUCTION)
|
||||
============================================
|
||||
|
||||
Ocelot has recently integrated `Rafty <https://github.com/TomPallister/Rafty>`_ which is an implementation of Raft that I have also been working on over the last year. This project is very experimental so please do not use this feature of Ocelot in production until I think it's OK.
|
||||
|
||||
Raft is a distributed concensus algorythm that allows a cluster of servers (Ocelots) to maintain local state without having a centralised database for storing state (e.g. SQL Server).
|
||||
|
||||
To get Raft support you must first install the Ocelot Rafty package.
|
||||
|
||||
``Install-Package Ocelot.Provider.Rafty``
|
||||
|
||||
Then you must make the following changes to your Startup.cs / Program.cs.
|
||||
|
||||
.. code-block:: csharp
|
||||
|
||||
public virtual void ConfigureServices(IServiceCollection services)
|
||||
{
|
||||
services
|
||||
.AddOcelot()
|
||||
.AddAdministration("/administration", "secret")
|
||||
.AddRafty();
|
||||
}
|
||||
|
||||
In addition to this you must add a file called peers.json to your main project and it will look as follows
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"Peers": [{
|
||||
"HostAndPort": "http://localhost:5000"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5002"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5003"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5004"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5001"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
Each instance of Ocelot must have it's address in the array so that they can communicate using Rafty.
|
||||
|
||||
Once you have made these configuration changes you must deploy and start each instance of Ocelot using the addresses in the peers.json file. The servers should then start communicating with each other! You can test if everything is working by posting a configuration update and checking it has replicated to all servers by getting their configuration.
|
||||
Raft (EXPERIMENTAL DO NOT USE IN PRODUCTION)
|
||||
============================================
|
||||
|
||||
Ocelot has recently integrated `Rafty <https://github.com/ThreeMammals/Rafty>`_ which is an implementation of Raft that I have also been working on over the last year. This project is very experimental so please do not use this feature of Ocelot in production until I think it's OK.
|
||||
|
||||
Raft is a distributed concensus algorythm that allows a cluster of servers (Ocelots) to maintain local state without having a centralised database for storing state (e.g. SQL Server).
|
||||
|
||||
To get Raft support you must first install the Ocelot Rafty package.
|
||||
|
||||
``Install-Package Ocelot.Provider.Rafty``
|
||||
|
||||
Then you must make the following changes to your Startup.cs / Program.cs.
|
||||
|
||||
.. code-block:: csharp
|
||||
|
||||
public virtual void ConfigureServices(IServiceCollection services)
|
||||
{
|
||||
services
|
||||
.AddOcelot()
|
||||
.AddAdministration("/administration", "secret")
|
||||
.AddRafty();
|
||||
}
|
||||
|
||||
In addition to this you must add a file called peers.json to your main project and it will look as follows
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"Peers": [{
|
||||
"HostAndPort": "http://localhost:5000"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5002"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5003"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5004"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5001"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
Each instance of Ocelot must have it's address in the array so that they can communicate using Rafty.
|
||||
|
||||
Once you have made these configuration changes you must deploy and start each instance of Ocelot using the addresses in the peers.json file. The servers should then start communicating with each other! You can test if everything is working by posting a configuration update and checking it has replicated to all servers by getting their configuration.
|
||||
|
||||
@ -5,7 +5,7 @@ Ocelot allows you to specify Aggregate ReRoutes that compose multiple normal ReR
|
||||
a client that is making multiple requests to a server where it could just be one. This feature allows you to start implementing back end for a front end type
|
||||
architecture with Ocelot.
|
||||
|
||||
This feature was requested as part of `Issue 79 <https://github.com/TomPallister/Ocelot/pull/79>`_ and further improvements were made as part of `Issue 298 <https://github.com/TomPallister/Ocelot/issue/298>`_.
|
||||
This feature was requested as part of `Issue 79 <https://github.com/ThreeMammals/Ocelot/pull/79>`_ and further improvements were made as part of `Issue 298 <https://github.com/ThreeMammals/Ocelot/issue/298>`_.
|
||||
|
||||
In order to set this up you must do something like the following in your ocelot.json. Here we have specified two normal ReRoutes and each one has a Key property.
|
||||
We then specify an Aggregate that composes the two ReRoutes using their keys in the ReRouteKeys list and says then we have the UpstreamPathTemplate which works like a normal ReRoute.
|
||||
|
||||
@ -140,13 +140,13 @@ The ReRoute above will only be matched when the host header value is somedomain.
|
||||
|
||||
If you do not set UpstreamHost on a ReRoute then any host header will match it. This means that if you have two ReRoutes that are the same, apart from the UpstreamHost, where one is null and the other set Ocelot will favour the one that has been set.
|
||||
|
||||
This feature was requested as part of `Issue 216 <https://github.com/TomPallister/Ocelot/pull/216>`_ .
|
||||
This feature was requested as part of `Issue 216 <https://github.com/ThreeMammals/Ocelot/pull/216>`_ .
|
||||
|
||||
Priority
|
||||
^^^^^^^^
|
||||
|
||||
You can define the order you want your ReRoutes to match the Upstream HttpRequest by including a "Priority" property in ocelot.json
|
||||
See `Issue 270 <https://github.com/TomPallister/Ocelot/pull/270>`_ for reference
|
||||
See `Issue 270 <https://github.com/ThreeMammals/Ocelot/pull/270>`_ for reference
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
@ -181,7 +181,7 @@ matched /goods/{catchAll} (because this is the first ReRoute in the list!).
|
||||
Dynamic Routing
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
This feature was requested in `issue 340 <https://github.com/TomPallister/Ocelot/issue/340>`_.
|
||||
This feature was requested in `issue 340 <https://github.com/ThreeMammals/Ocelot/issue/340>`_.
|
||||
|
||||
The idea is to enable dynamic routing when using a service discovery provider so you don't have to provide the ReRoute config. See the docs :ref:`service-discovery` if
|
||||
this sounds interesting to you.
|
||||
|
||||
@ -113,7 +113,7 @@ Ocelot will add this token to the consul client that it uses to make requests an
|
||||
Eureka
|
||||
^^^^^^
|
||||
|
||||
This feature was requested as part of `Issue 262 <https://github.com/TomPallister/Ocelot/issue/262>`_ . to add support for Netflix's
|
||||
This feature was requested as part of `Issue 262 <https://github.com/ThreeMammals/Ocelot/issue/262>`_ . to add support for Netflix's
|
||||
Eureka service discovery provider. The main reason for this is it is a key part of `Steeltoe <https://steeltoe.io/>`_ which is something
|
||||
to do with `Pivotal <https://pivotal.io/platform>`_! Anyway enough of the background.
|
||||
|
||||
@ -158,7 +158,7 @@ is provided by the Pivotal.Discovery.Client NuGet package so big thanks to them
|
||||
Dynamic Routing
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
This feature was requested in `issue 340 <https://github.com/TomPallister/Ocelot/issue/340>`_. The idea is to enable dynamic routing when using a service discovery provider (see that section of the docs for more info). In this mode Ocelot will use the first segment of the upstream path to lookup the downstream service with the service discovery provider.
|
||||
This feature was requested in `issue 340 <https://github.com/ThreeMammals/Ocelot/issue/340>`_. The idea is to enable dynamic routing when using a service discovery provider (see that section of the docs for more info). In this mode Ocelot will use the first segment of the upstream path to lookup the downstream service with the service discovery provider.
|
||||
|
||||
An example of this would be calling ocelot with a url like https://api.mywebsite.com/product/products. Ocelot will take the first segment of
|
||||
the path which is product and use it as a key to look up the service in consul. If consul returns a service Ocelot will request it on whatever host and port comes back from consul plus the remaining path segments in this case products thus making the downstream call http://hostfromconsul:portfromconsul/products. Ocelot will apprend any query string to the downstream url as normal.
|
||||
|
||||
Reference in New Issue
Block a user