Optimizing the Response

In the following sections, we'll first look at the default response for a simple YQL statement and then examine how a modification to the same YQL statement can cause YQL to return a bloated response. Finally, we'll show you how to configure YQL to return an optimized response.

Default Response

The simple YQL statement querying weather data below uses the filter location=90210 and requests all of the fields.

select * from weather.forecast where location=90210

This query returns a single response item, which contains two yweather:forecast sub-elements (one containing the forecast information for the current, and the other, the forecast information for the next day). In the default response shown below, notice that YQL places the yweather:forecast sub-elements in one item element:

Bloated Response

The response will bloat though if a SELECT statement specifies one or more fields for projection, and those fields match repeated sub-elements with the same parent in the response. For the sake of clarification, let's look again at our SELECT statement that queries weather data, its related response, and then make one modification to see how the response changes.

Here was our original SELECT statement querying weather data:

select * from weather.forecast where location=90210

Ignoring the actual returned data, let's just look at the basic structure of the returned response shown below. Notice that the item element has two instances of the sub-element yweather:forecast.

Suppose we take the sub-element yweather:forecast and use it as a projection field so that our SELECT statement now looks like the following:

select item.yweather:forecast from weather.forecast where location=90210

The returned response for our modified query will look like this:

Using the sub-element yweather:forecast as a projection field caused the response to have multiple channel and item elements. This bloating would only increase if the query has title, link, and description set as projection fields because now the response will contain duplicate title, link, and description elements inside the repeated XML nodes.

For example, when we modify our query to request the projection fields title, link, and description with the following:

select title, link, description, item.yweather:forecast from weather.forecast where location=90210

You can see that our response becomes even more bloated:

In the following sections, we will look at how users can specify the crossProduct=optimized request parameter to configure YQL to optimize responses by removing redundant data.

Configuring YQL to Optimize the Response

In the Bloated Response section, we saw how the response for a one-day weather forecast contained redundant data when the SELECT statement specified nested fields as projection fields. Imagine how large the response for our weather query would be if it contained the forecast for the next 7 days.

Fortunately, YQL lets you append the request parameter crossProduct=optimized to the the YQL Web Service URL to suppress the duplicate information from the response. To see how the request parameter crossProduct=optimized optimizes the response, click the link below to run the statement in the YQL console:

select title, link, description, item.yweather:forecast from weather.forecast where location=90210

Notice that the returned response contains a single item with two yweather:forecast sub-elements, with the title, link, and description elements (which is common across these sub-elements) appearing only once. This is because the YQL Web service URL had the appended query parameter crossProduct=optimized, which, from the YQL Console, you can see in the browser's address bar or in the THE REST QUERY text field.

Note, only projection fields that are not also specified as local filters (which is true for all the projection fields in the above query) will respond to this type of optimization.

Table of Contents