tk/Ocelot
1
0
Fork 0
mirror of https://github.com/nsnail/Ocelot.git synced 2025-09-18 13:42:41 +08:00
Code Issues Packages Projects Releases Wiki Activity

Rename all ReRoute to Route to move closer to YARP +semver: breaking

Browse Source
This commit is contained in:
Tom Pallister
2020-05-23 20:50:05 +01:00
committed by GitHub
parent fe3e8bd23a
commit 3439be8927
269 changed files with 23591 additions and 23605 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/features/requestaggregation.rst
View File

@@ -1,15 +1,15 @@
Request Aggregation
===================
Ocelot allows you to specify Aggregate ReRoutes that compose multiple normal ReRoutes and map their responses into one object. This is usually where you have
Ocelot allows you to specify Aggregate Routes that compose multiple normal Routes and map their responses into one object. This is usually where you have
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/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.
Obviously you cannot have duplicate UpstreamPathTemplates between ReRoutes and Aggregates. You can use all of Ocelot's normal ReRoute options apart from RequestIdKey (explained in gotchas below).
In order to set this up you must do something like the following in your ocelot.json. Here we have specified two normal Routes and each one has a Key property.
We then specify an Aggregate that composes the two Routes using their keys in the RouteKeys list and says then we have the UpstreamPathTemplate which works like a normal Route.
Obviously you cannot have duplicate UpstreamPathTemplates between Routes and Aggregates. You can use all of Ocelot's normal Route options apart from RequestIdKey (explained in gotchas below).
Advanced register your own Aggregators
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -22,7 +22,7 @@ The ocelot.json setup is pretty much the same as the basic aggregation approach
.. code-block:: json
{
"ReRoutes": [
"Routes": [
{
"DownstreamPathTemplate": "/",
"UpstreamPathTemplate": "/laura",
@@ -56,7 +56,7 @@ The ocelot.json setup is pretty much the same as the basic aggregation approach
],
"Aggregates": [
{
"ReRouteKeys": [
"RouteKeys": [
"Tom",
"Laura"
],
@@ -66,7 +66,7 @@ The ocelot.json setup is pretty much the same as the basic aggregation approach
]
}
Here we have added an aggregator called FakeDefinedAggregator. Ocelot is going to look for this aggregator when it tries to aggregate this ReRoute.
Here we have added an aggregator called FakeDefinedAggregator. Ocelot is going to look for this aggregator when it tries to aggregate this Route.
In order to make the aggregator available we must add the FakeDefinedAggregator to the OcelotBuilder like below.
@@ -76,7 +76,7 @@ In order to make the aggregator available we must add the FakeDefinedAggregator
.AddOcelot()
.AddSingletonDefinedAggregator<FakeDefinedAggregator>();
Now when Ocelot tries to aggregate the ReRoute above it will find the FakeDefinedAggregator in the container and use it to aggregate the ReRoute.
Now when Ocelot tries to aggregate the Route above it will find the FakeDefinedAggregator in the container and use it to aggregate the Route.
Because the FakeDefinedAggregator is registered in the container you can add any dependencies it needs into the container like below.
.. code-block:: csharp
@@ -106,7 +106,7 @@ In order to make an Aggregator you must implement this interface.
Task<DownstreamResponse> Aggregate(List<HttpContext> responses);
}
With this feature you can pretty much do whatever you want because the HttpContext objects contain the results of all the aggregate requests. Please note if the HttpClient throws an exception when making a request to a ReRoute in the aggregate then you will not get a HttpContext for it but you would for any that succeed. If it does throw an exception this will be logged.
With this feature you can pretty much do whatever you want because the HttpContext objects contain the results of all the aggregate requests. Please note if the HttpClient throws an exception when making a request to a Route in the aggregate then you will not get a HttpContext for it but you would for any that succeed. If it does throw an exception this will be logged.
Basic expecting JSON from Downstream Services
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -114,7 +114,7 @@ Basic expecting JSON from Downstream Services
.. code-block:: json
{
"ReRoutes": [
"Routes": [
{
"DownstreamPathTemplate": "/",
"UpstreamPathTemplate": "/laura",
@@ -148,7 +148,7 @@ Basic expecting JSON from Downstream Services
],
"Aggregates": [
{
"ReRouteKeys": [
"RouteKeys": [
"Tom",
"Laura"
],
@@ -157,16 +157,16 @@ Basic expecting JSON from Downstream Services
]
}
You can also set UpstreamHost and ReRouteIsCaseSensitive in the Aggregate configuration. These behave the same as any other ReRoutes.
You can also set UpstreamHost and RouteIsCaseSensitive in the Aggregate configuration. These behave the same as any other Routes.
If the ReRoute /tom returned a body of {"Age": 19} and /laura returned {"Age": 25} the the response after aggregation would be as follows.
If the Route /tom returned a body of {"Age": 19} and /laura returned {"Age": 25} the the response after aggregation would be as follows.
.. code-block:: json
{"Tom":{"Age": 19},"Laura":{"Age": 25}}
At the moment the aggregation is very simple. Ocelot just gets the response from your downstream service and sticks it into a json dictionary
as above. With the ReRoute key being the key of the dictionary and the value the response body from your downstream service. You can see that the object is just
as above. With the Route key being the key of the dictionary and the value the response body from your downstream service. You can see that the object is just
JSON without any pretty spaces etc.
All headers will be lost from the downstream services response.
@@ -179,7 +179,7 @@ It will not change the aggregate response into a 404 even if all the downstreams
Gotcha's / Further info
-----------------------
You cannot use ReRoutes with specific RequestIdKeys as this would be crazy complicated to track.
You cannot use Routes with specific RequestIdKeys as this would be crazy complicated to track.
Aggregation only supports the GET HTTP Verb.