EdgeWorkers allows you to make HTTP requests from within an event handler, providing a convenient way to fetch resources across the network.  This includes resources from a third party, like a call to a weather API.  In this example, I’m using an EdgeWorker retrieve local weather information:

There are a few requirements to keep in mind when using HTTP sub-requests:

1. Dynamic Compute Tier

The first is that they can only be used with the Dynamic Compute resource tier.  Additional information on resource tier limitations can be found here.

2. Domain Must Be On Akamai

You can only request a hostname that is served through the Akamai network.  I’m calling the weather API openweathermap.org.  This domain is NOT on the Akamai network, so I’ve got to proxy it through an active property configuration.  Let’s take a closer look at how I set this up:

A.  First, I created an EdgeWorker with an httpRequest (line 26) in the onClientRequest (line 17) event handler.  I used EdgeScape to obtain the user’s city (19-22) and used the city variable in the building of the Domain variable (23).  Note that the domain being called in the EdgeWorker is NOT openweathermap.org.  Rather, it’s my own domain, duanedorch.com, which is configured on the Akamai network.

B.  Next, I added this EdgeWorker to the property for my domain:

I added an EdgeWorkers behavior to my property that activates on the match criteria of the path /weather.  So anyone that goes to duanedorch.com/weather will receive the output of the EdgeWorker.

C.  Next I defined a new Origin Server behavior with a match criteria of /weatherapi*, which will match the domain from the httpRequest() in the EdgeWorker.  The behavior provides the details for the real domain that I want to call, which is api.openweathermap.org.

Now that the third party domain is defined in my property, I can apply other standard property behaviors like caching and prefreshing to it as well.

This third party is now set up on the Akamai network and ready to use once the EdgeWorker is activated.  Of course, you only want to take this action for third party domains that you trust.

3. Execution limits and retry

There are some important execution limits associated with HTTP sub-requests.  As of the time of this writing, the following limits should be observed:

• Maximum wall time per HTTP sub-request 1.5 seconds
• Maximum response size per HTTP sub-request 5 MB

The sub-request and EdgeWorker will fail if these limits are exceeded.  You’ll benefit from using the enhanced debug headers when trying to understand the reason for an EdgeWorkers failure.  You may also want to implement the Site Failover Property Manager behavior to define what happens when an EdgeWorkers function fails.

More information on HTTP sub-requests in EdgeWorkers can be found in the EdgeWorkers documentation.