Lumen help
Version 3.0 beta will be released in 1Q 2022. If you’d like to learn more before then, contact your account or support team.
The following resources are available to discover caching configuration management API version 2.0:
Lumen has simplified the caching provisioning process through a new suite of restful web services. The following section assumes familiarity with the Media portal API framework and is primarily focused on the differences between version 1.0 and version 2.0.
In order to take advantage of version 2.0, all properties for a given service image (SCID) must first be migrated to a new format by your local Lumen CDN support team. Note that you do not have to convert all SCIDs at once.
v1.0: https://ws.lumen.com/v1.0/serviceConfiguration/[Access Group ID]/[SCID]/
v2.0: https://ws.lumen.com/v2.0/serviceConfiguration/[SubscriberID]/
Learn more about subscriber/SCID mappings per API key
Creating or updating a configuration in version 1.0 involves several granular API calls to enact caching configuration settings even though they are all for the same subscriber/service. In version 2.0, all settings for a single SCID can be made in a single API call because all configuration settings for the subscriber are represented in a single JSON body.
With version 1.0, each SCID contained a single configuration. Changes to this configuration were applied to the CDN network within 15 minutes. With version 2.0, there are several improvements to note:
When promoting a configuration with many properties, the response wait time can take several minutes. Once the response is received, it will be propagated to the edge within one or two minutes.
Version 2.0 supports more configuration options, such as IP/CIDR groups, accept-encoding overrides, and dynamic content transformation.
Stored configurations are versioned, and any version can be promoted to an environment making it easy to revert to a previous version. When saving or promoting, a comment can be provided to aid when reviewing collaborative input from multiple users. Each environment has a version number that represents a count of promotions.
Except for cache control header override (CCHO) and query string handling (QSH), features are defined once and referred to within match rules reducing the overhead of managing duplicate configuration settings across multiple properties.
Within a given instances of a configuration (exp. MyConfig version 1), all element classes, such as a geo region, IDs must be unique. However, origin IDs must be unique at the SCID/subscriber level. Therefore, when promoting a new configuration that contains an origin ID that overlaps with a previously deployed origin ID for a completely different configuration, it will fail. To ensure uniqueness at the SCID/subscriber level, we recommend using a convention, such as appending EPOCH time when generating the ID.
In order to offer more flexibility in the near future, version 2.0 represents caching properties differently.
Request
Example: https://ws.lumen.com/serviceConfiguration/v1.0/[Access Group ID]/[SCID]
Body
{
"originserver":{
"host":" test.origin.com",
"port": "8001",
"protocol": "http"
},
"aliases":[
"test1.caching.cdn.lumen.net",
"test2.caching.cdn.lumen.net"
]
}
In version 2.0, all configuration settings can be sent in a single call. The following section describes the configuration elements that equate to creating a property. In this case an origin definition, alias definition are correlated with a reporting ID and origin ID. The primary alias is entered as the reporting ID name.
Each property must have at least one match rule to match group 0 with a defined traffic type in order to be valid.
The presentation of this API is broken into different categories corresponding to the major service configuration components.
Note: Caching configuration management version 1.0 is now deprecated. It will continue to function for the remainder of 2020 or until your caching service image is converted to a format that is no longer supported by version 1.0.
Category | Function | Scope |
Alias | Retrieve, add, and remove aliases for a property. |
Property |
Configuration groups | Retrieve, add, update, and remove configuration groups for access control, cache control, and content manipulation rules associated with a resource group filter. | Service or property |
Geo definition | Retrieve, create, update, and delete a geo definition for geo-blocking. | Service or property |
Get configuration information | Returns configuration information for Lumen CDN service(s) associated to an access group, service component identifier, or network identifier. | Service |
Origin | Retrieve and update the origin server section of a property. | Property |
Propagation of configuration changes | The service configuration services for caching configuration management potentially affect the operation of hundreds or thousands of CDN devices globally. To efficiently manage configuration across this global network, there is a multi-tier architecture for managing network configuration where changes are queued and propagate in batch. As a result, you may experience some delay before configuration changes take effect. In particular:
|
|
Properties | API services for properties provide the means to create, retrieve, deactivate and reactivate properties. The create and get operations include only the basic attribution of a property, limited to origin and alias information. | Service or property |
Property origin aliases | Retrieve, add, deactivate/reactivate a property. | Service or property |
Resource groups | Retrieve, add, update, and remove resource groups (typically path based URI filters). | Service or property |
Token | Retrieve, add, update, and remove token definitions for token authentication. | Service or property |
Explore Media portal
API articles