-
Notifications
You must be signed in to change notification settings - Fork 44
W-13513395 cm traffic management gr #524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
W-13513395 cm traffic management gr #524
Conversation
+ | ||
. Click *Add header (optional)*, if this is not your first header. | ||
. Enter the header name in the first box. | ||
. Enter `true` or `false` dependent on if the header must be present. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
. Enter `true` or `false` dependent on if the header must be present. | |
. Enter `true` or `false`, depending on whether the header must be present. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: ...the header present in the request
@@ -33,4 +33,8 @@ instance. | |||
|
|||
When you are promoting or importing an API instance, you do not have options to alter the configuration. However, when you add a new API instance, you need to the downstream and the upstream configuration settings. | |||
|
|||
The following diagram demonstrates the upstream and downstream configurations settings relationship to your upstream service and consumer application. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: ...shows the relationship of the upstream and downstream configuration settings to your upstream service and consumer application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way you have it written, you would need to change "configurations settings relationship" to "configuration settings' relationship." This wording is awkward.
|
||
Flex Gateway version 1.5.x or later supports API instances that expose multiple upstream services through a single consumer endpoint. | ||
|
||
Flex Gateway manages traffic by using different routes with defined rulesets and route order to direct traffic to different sets of upstream services. Each API instance supports multiple routes that can each direct traffic to multiple upstream services. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion to shorten the wording: Flex Gateway uses different routes... (since you mention that it directs traffic, I don't think you need "manages traffic" as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is route order defined? This wording implies that it is defined on each route, but that is probably incorrect. If you flip the wording, it would be clearer:
Flex Gateway uses the configured route order and routes with defined rulesets...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion to split the last sentence in two. "multiple routes" does not really go with "each."
|
||
=== Routes | ||
|
||
Each API instance supports up to 10 routes and each route can support up to 10 upstream services. You configure what routes receive what requests by defining route rules and route order. Only one route per API instance is required. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each API instance supports up to 10 routes and each route can support up to 10 upstream services. You configure what routes receive what requests by defining route rules and route order. Only one route per API instance is required. | |
Each API instance supports up to 10 routes and each route can support up to 10 upstream services. Configure what requests a route can receive by defining route rules and a route order. Only one route per API instance is required. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe: At least one route per API instance is required.
+ | ||
The *Headers* rule defines what headers are required to be present or not present for this route to service the request. | ||
+ | ||
For this rule, you must define the header name and a `true` or `false` value of whether or not the header is present. Only requests that meet all the specified header requirements are sent to this route. Additional headers present in the request that are not specifically defined in the rules are ignored. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are they writing true
and false
or selecting this value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Writing
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
+ | ||
Defines the types of request methods that the route can service. | ||
+ | ||
You can select multiple methods for each route. Only requests that are one of the defined methods are directed to this route. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are requests a method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you could have GET requests or POST requests and so on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah - REST requests
|
||
To view and edit route rules, click *Route Rules*. | ||
|
||
All rules are optional. Not defining a value for a rule means that aspect of the request is not considered. For example, not specifying a host means that the route can service any host if the request meets the other route rules. Not defining any rule means that the route can service every request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence is problematic. (See my earlier review comment on this.)
|
||
Route ordering is very important when a request can meet the route rules of multiple routes. You should order the routes with more complex route rules first. If you do not define a route order, routes are ordered in the order they were created. | ||
|
||
For example, in a configuration where route one has the `GET` method defined as a rule and route two has no route rules defined, all `GET` requests are sent to route one and all other requests are sent to route two. If the route order was reversed and route one had no route rules, Flex Gateway would direct all requests to route one before any `GET` requests could reach route two. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, in a configuration where route one has the `GET` method defined as a rule and route two has no route rules defined, all `GET` requests are sent to route one and all other requests are sent to route two. If the route order was reversed and route one had no route rules, Flex Gateway would direct all requests to route one before any `GET` requests could reach route two. | |
For example, in a configuration in which route one has the `GET` method defined as a rule and route two has no route rules defined, all `GET` requests are sent to route one and all other requests are sent to route two. If the route order was reversed and route one had no route rules, Flex Gateway would direct all requests to route one before any `GET` requests could reach route two. |
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
Co-authored-by: Diane E Hirsch <diane.hirsch@mulesoft.com>
Writer's Quality Checklist
Before merging your PR, did you: