<commit_before>= Expression Language
:page-sidebar: apim_sidebar
:page-permalink: apim_publisherguide_expression_language.html
:page-folder: apim/user-guide/publisher

The Gravitee.io Expression Language (EL for short) is one of the key feature
that can be used by API publisher to configure several points / services of an API.

This expression language is a powerful language that support querying and
manipulating an object graph and is based on the great http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html[SpEL] (Spring Expression Language).
This also mean that you can do exactly all the things described in the previous
link.

Gravitee.io is extending SpEL capabilities by providing useful objects and properties
inside the expression language context.

== Syntax
The Expression Language syntax is as follow:

`{#request.id}`

== API
=== Properties

As an API publisher, you can define properties for your API. These properties are
automatically _injected_ into the expression language context to be used later.

=== Example

* Get the value of the property `my-property` defined in API properties:
`{#properties['my-property']}`

=== Endpoints
When defining endpoints for your API, you must have to give them a _name_ which
must be a unique identifier across all the endpoints of this API.

Once done, this identifier can be used to get an endpoint reference (ie. uri).

For example: when you're creating an API, a _default_ endpoint is created,
corresponding to the value you set for the backend property. This endpoint can
be retrieved using EL by using the following syntax:

`{#endpoints['default']}`

== Request
=== Properties
|===
|Property |Description |Type |Always present

.^|id
|Request identifier
^.^|string
^.^|X

.^|headers
|Request headers
^.^|key / value
^.^|X

.^|params
|Request query parameters
^.^|key / value
^.^|X

.^|paths
|Request path parts
^.^|array of string
^.^|X

.^|content
|Request body content
^.^|array of string
^.^|-
|===

=== Example

* Get the value of the `Content-Type` header for an incoming HTTP request:
`{#request.headers['content-type']}`

* Get the second part of the request path:
`{#request.paths[1]}`

== Request context
=== Properties
|===
|Property |Description |Type |Always present

.^|attributes
|Request context attributes
^.^|key-value
^.^|X
|===

=== Attributes
When the gateway handles an incoming HTTP request, some attributes are
automatically created. These attributes are:

|===
|Property |Description |Type |Nullable

.^|context-path
|Context-path
^.^|string
^.^|-

.^|resolved-path
|Resolved-path is the path defined in policies
^.^|string
^.^|-

.^|application
|The authenticated application doing incoming HTTP request
^.^|string
^.^|X (for keyless plan)

.^|api
|Called API
^.^|string
^.^|-

.^|user-id
|The user identifier of incoming HTTP request:

* Api-key value for api-key based plan

* Remote IP for keyless based plan

^.^|string
^.^|-

.^|plan
|Plan used to manage incoming HTTP request
^.^|string
^.^|-
|===

Also, some policies (like the <<apim_policies_oauth2.adoc#attributes, OAuth2 policy>>)
are registering some other attributes in the context. Please check the
documentation of the policies you are using to be aware of them.

=== Example

* Get the value of the `user-id` attribute for an incoming HTTP request:

`{#context.attributes['user-id']}`

* Get the value of the `plan` attribute for an incoming HTTP request:

`{#context.attributes['plan']}`


== Policies
Expression language can be used to configure some part of policies configuration.
It's up to the policy to specify if its supports EL or not.

== Mixin
<commit_msg>fix: add the api-key attribute for context<commit_after>= Expression Language
:page-sidebar: apim_sidebar
:page-permalink: apim_publisherguide_expression_language.html
:page-folder: apim/user-guide/publisher

The Gravitee.io Expression Language (EL for short) is one of the key feature
that can be used by API publisher to configure several points / services of an API.

This expression language is a powerful language that support querying and
manipulating an object graph and is based on the great http://docs.spring.io/spring/docs/current/spring-framework-reference/html/expressions.html[SpEL] (Spring Expression Language).
This also mean that you can do exactly all the things described in the previous
link.

Gravitee.io is extending SpEL capabilities by providing useful objects and properties
inside the expression language context.

== Syntax
The Expression Language syntax is as follow:

`{#request.id}`

== API
=== Properties

As an API publisher, you can define properties for your API. These properties are
automatically _injected_ into the expression language context to be used later.

=== Example

* Get the value of the property `my-property` defined in API properties:
`{#properties['my-property']}`

=== Endpoints
When defining endpoints for your API, you must have to give them a _name_ which
must be a unique identifier across all the endpoints of this API.

Once done, this identifier can be used to get an endpoint reference (ie. uri).

For example: when you're creating an API, a _default_ endpoint is created,
corresponding to the value you set for the backend property. This endpoint can
be retrieved using EL by using the following syntax:

`{#endpoints['default']}`

== Request
=== Properties
|===
|Property |Description |Type |Always present

.^|id
|Request identifier
^.^|string
^.^|X

.^|headers
|Request headers
^.^|key / value
^.^|X

.^|params
|Request query parameters
^.^|key / value
^.^|X

.^|paths
|Request path parts
^.^|array of string
^.^|X

.^|content
|Request body content
^.^|array of string
^.^|-
|===

=== Example

* Get the value of the `Content-Type` header for an incoming HTTP request:
`{#request.headers['content-type']}`

* Get the second part of the request path:
`{#request.paths[1]}`

== Request context
=== Properties
|===
|Property |Description |Type |Always present

.^|attributes
|Request context attributes
^.^|key-value
^.^|X
|===

=== Attributes
When the gateway handles an incoming HTTP request, some attributes are
automatically created. These attributes are:

|===
|Property |Description |Type |Nullable

.^|context-path
|Context-path
^.^|string
^.^|-

.^|resolved-path
|Resolved-path is the path defined in policies
^.^|string
^.^|-

.^|application
|The authenticated application doing incoming HTTP request
^.^|string
^.^|X (for keyless plan)

.^|api
|Called API
^.^|string
^.^|-

.^|user-id
|The user identifier of incoming HTTP request:

* The subscription id for api-key based plan

* Remote IP for keyless based plan

^.^|string
^.^|-

.^|plan
|Plan used to manage incoming HTTP request
^.^|string
^.^|-

.^|api-key
|the api-key used (in case of an api-key based plan)
^.^|string
^.^|X (for no api-key plan)
|===

Also, some policies (like the <<apim_policies_oauth2.adoc#attributes, OAuth2 policy>>)
are registering some other attributes in the context. Please check the
documentation of the policies you are using to be aware of them.

=== Example

* Get the value of the `user-id` attribute for an incoming HTTP request:

`{#context.attributes['user-id']}`

* Get the value of the `plan` attribute for an incoming HTTP request:

`{#context.attributes['plan']}`


== Policies
Expression language can be used to configure some part of policies configuration.
It's up to the policy to specify if its supports EL or not.

== Mixin

{'fraction_non_alphanumeric': 0.1106046386915136, 'fraction_numerical': 0.0008043973723019171, 'mean_word_length': 4.647236941710825, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2365800', 'n_tokens_mistral': 2237, 'n_tokens_neox': 2153, 'n_words': 948}