Release: Amazon E-Commerce Service on 2007-04-10

Release Notes>Product Advertising API>Release: Amazon E Commerce Service on 2007 04 10
This release of ECS introduces new search indices in the FR, JP, and UK locales, a significant increase in the number of Variation dimensions returned, an increase in the number of search bins returned, and the first publications of a completely rewritten ECS Developer Guide.

Details

Submitted By: Craig@AWS
Created On: April 10, 2007 7:11 PM GMT
Last Updated: April 12, 2007 9:28 PM GMT

These release notes provide a summary of all New Features, Resolved Issues, and Known Issues in the latest version of Amazon's E-Commerce Service (ECS). For changes made in previous ECS versions, go to http://aws.amazon.com/resources.

Release Date: 2007-04-04
Latest WSDL/API Version: 2007-04-04

New Features

The following table describes the new features found in this release.

Applies
To

Feature
Description
US X

ECS now returns the first 25 search bins in ItemSearch results.

Previously, ECS returned only the first 10 search bins in ItemSearch results. That limit has been increased to 25 search bins. To return search bins, use the SearchBins response group.
CA  
DE  
FR  
JP  
UK  
US X

ECS now returns many more Variation dimensions.

A Variation dimension is a characteristic that differentiates Variations. For example, the same style shirt can vary by size and color. Size and color are the Variation dimensions. ECS now returns many more dimensions, including:

  • GemType (string)
  • HandOrietation (string)
  • HardwarePlatform (string)
  • PackageQuantity (nonNegativeInteger)
  • ItemDimensions/Length (DecimalWithUnits)
  • ItemDimensions/Width (DecimalWithUnits)
  • MetalType (string)
  • Model (string)
  • OperatingSystem (string)
  • ProductTypeSubcategory (string)
  • ScentName (string)
  • StyleName (string)
  • TotalDiamondWeight (DecimalWithUnits)
  • TotalGemWeight (DecimalWithUnits)
CA X
DE X
FR X
JP X
UK X
US X

ECS no longer supports the Restaurant search index.

In the past, the US locale supported the Restaurant search index, which returned restaurant information in select cities. This search index is no longer supported. There is no alternate way to obtain this information using ECS.

The ItemSearch parameters cuisine, city, and neighborhood, which were used in conjunction with the Restaurant search index will be deprecated over time. Currently, there is no use for these parameters.

CA  
DE  
FR  
JP  
UK  
US X

A new item attribute, IsCategoryRoot, is now returned per Marketplace with browse node response groups. This element is not useful with the Books search index.



Search results can return with items listed under multiple browse nodes. Some nodes, however, are more relevant that others. The IsCategoryRoot response element identifies which browse node is the most relevant for an item. This functionality will help vendors classify items for sale. The element applies to the marketplace specified in the request. So, it is possible for the IsCategoryRoot value to be different across marketplaces.

CA X
DE X
FR X
JP X
UK X
US  

ECS provides new search indices for the FR, JP, and UK locales.



ECS has added support for the following search indices in the following locales:

  • FR—Toys
  • JP—Watches
  • UK—Sporting Goods

See the Amazon E-Commerce Developer Guide for associated sort parameters.

CA  
DE  
FR X
JP X
UK X
US X

New ECS developer guide introduced with this release.

With this release, we introduce a completely rewritten version of the Amazon E-Commerce Developer Guide. The guide provides full explanations of the most current ECS functionality in a totally reorganized format. We expect you to find the information more completely explained and better organized.

CA X
DE X
FR X
JP X
UK X

Resolved Issues

The following table describes the issues resolved in the latest release of ECS.

Applies
To

Issue
Resolution
US X

Some ASINs returned by BrowseNodeLookup failed to work in ItemLookup requests.

BrowseNodeLookup used to return items that third party sellers wanted blocked. These items were returned when the following response groups were used: TopSellers, NewReleases, CartTopSellers, CartNewReleases, Accessories, and SimilarProducts. These items are no longer returned by BrowseNodeLookup.

CA  
DE  
FR  
JP  
UK  
US X

ItemSearch requests that searched the HomeGarden Search Index by Brand returned errors.

ItemSearch requests that search the HomeGarden Search Index by Brand no longer return errors.

CA  
DE X
FR  
JP  
UK X
US X

Search bins based on price failed to return <Value> values when the price exceeded 10000.

All search bins should contain names and values. These labels specify the range of values in the bin. When values exceeded 10000, values were not included in the response. This problem has been fixed and values are being returned as expected.

CA  
DE  
FR  
JP  
UK  
US  

Data returned in the JP locale was sometimes incorrectly encoded thus making the response nonsensical.

Some data in the JP locale was incorrectly encoded. ECS passed along that data, which caused some responses to look nonsensical. Now, ECS is able to detect incorrectly encoded data and encode it correctly.
CA  
DE  
FR  
JP X
UK  

 

Known Issues

The following issues describe irregular behavior seen in ECS 4.0 functionality:

Issue Description Impact
The EAN field does not support ISBN-13 in the JP locale. ISBN numbers have increased to 13 digits. This is larger than it was before. The existing EAN field can hold 13 digits. ItemSearch requests using the EAN field this way, however, return inaccurate results. JP locale ItemSearch requests that use the EAN field for the ISBN number. The workaround is to use the ISBN IdType parameter in an ItemLookup request where the ItemId is an ISBN number of a book. The ISBN value works only with the books search index.
ItemSearch using Browsenodes when the search index is PetSupplies does not work correctly. A search index is required with every ItemSearch request. Results are inaccurate when the Browsenodes parameter is also used in such a request. PetSupplies is a subset of the Kitchen search index, which does return accurate results. The work around is to use the Kitchen search index instead of PetSupplies.
The BrowseNodeLookup operation often returns inaccurate results for top sellers when the browse node in the request is the root node of a category. Browsenode lookup is often used to find the top seller in the browsenode category. When the browsenode is at the top of the category, the top sellers list is inaccurate. When trying to find top sellers in a root browse node. The workaround is to use one of the child browse nodes with the TopSellers response group.
Some of the browse node IDs listed in the ECS Developer Guide are out of date. Browse nodes are dynamic and can change during the course of a book's publication. For this reason, you should always validate a browsenode number before using it. When trying to use browse node IDs for various reasons.
The ListFull and ListInfo response groups sometimes return an incorrect value for TotalItems. The discrepancy arises when the response sometimes includes invalid ASINs as part of the total. Applications trying to use TotalItems programmatically can run into problems.
Items returned by ItemSearch may have prices that fall outside of the range specified by MaximumPrice and MinimumPrice. The ItemSearch parameters, MaximumPrice and MinimumPrice, should limit the items returned according to the specified price range. Sometimes, items are returned whose prices fall outside of the specified range. ItemSearch requests that use both MaximumPrice and MinimumPrice.
ItemSearch requests based on Actor or Director return the same results. The source data in the database does not distinguish between actors and directors. ItemSearch requests based on Actor or Director.
Salesrank values in the CA and EU locales do not match the values returned by the retail website in those locales. Salesrank values given by ECS and Amazon's retail web site differ from those given, at times, in the CA and EU locales. ItemSearch requests that are sorted by Salesrank.
Not all parent browse nodes are returned by BrowseNodeInfo.

The response group, BrowseNodeInfo, used in BrowseNodeLookup requests returns the child and parent browse nodes of the browse node specified in the request. When a browse node has multiple parents, however, only one of the parent browse nodes is returned in the response. That is why there might be a difference between the ECS response and the result displayed on Amazon’s retail web site. BrowseNodeInfo returns the entire lineage of both child and parent browse nodes. For example, in the following response snippet, the parentage of the browse node in the request, Social Sciences, is traced all the way up the browse node tree to the root browse node, Books. Also, all of the children of the node, Social Sciences, are returned. For the sake of brevity, the following response snippet shows only some of the returned child browse nodes.

<Item>
<ASIN>0131856340</ASIN>
-<BrowseNodes>
  -<BrowseNode>
   <BrowseNodeId>11232</BrowseNodeId>
   <Name> Social Sciences</Name>
     -<Ancestors>
      -<BrowseNode>
      <BrowseNodeId>53</BrowseNodeId>
      <Name>Nonfiction</Name>
      -<Ancestors>
       -<BrowseNode>
       <BrowseNodeId>1000</BrowseNodeId>
       <Name>Subjects</Name>
      -<Ancestors>
        -<BrowseNode>
        <BrowseNodeId>283155</BrowseNodeId>
        <Name>Books</Name>
      </BrowseNode>
    </BrowseNode>
  </BrowseNode>
- <Children>
  - <BrowseNode>
      <BrowseNodeId>11233</BrowseNodeId>
      <Name>Anthropology</Name>
    </BrowseNode>
  - <BrowseNode>
      <BrowseNodeId>11242</BrowseNodeId>
      <Name>Archaeology</Name>
    </BrowseNode>
  - <BrowseNode>
      <BrowseNodeId>3048861</BrowseNodeId>
      <Name>Children's Studies</Name>
    </BrowseNode>
  </Children>
</BrowseNodes>

Notice that all of the nodes in the response show only one parent node, for example, the parent node of Social Sciences is Nonfiction. Only a single parent node would be returned even if a node had multiple parents.

BrowsenodeLookups that attempt to work "up" the browsenode hierarchy.
Items sorted by salesrank are returned out of order. In an ItemSearch request where Sort=salesrank, you would expect the items to be returned in order of their sales rank from best (1) to worst (large number). The sales rank values for items change frequently. The ECS sales rank updates lag behind the sales rank updates on the retail website. So, in an ItemSearch request, although the sales rank numbers are out of order in the ECS response, the items are, in fact, ordered according to the sales rank computed on the retail website. In this way, the sales rank order of items returned by ECS and Amazon’s retail website match. One alternative in the US locale is to use the TopSellers response group to get the top 10 bestsellers. Those items are returned in order. ItemSearch requests that are sorted by Salesrank.
ItemSearch power searches sometimes return different results when the sort parameter is specified versus when it is not specified. Submitting the same request twice, once with and once without the sort parameter, potentially returns different sets of results. ItemSearch power searches.
The parameter, pubdate, which is used in ItemSearch Power searches is not working correctly. This parameter sometimes does not return results for the specified pubdate value when it should. ItemSearch power searches that use pubdate.
Changing access to lists often requires up to twenty-four hours to take effect. Only lists made public by a customer are returned by ListSearch. A customer can change access restrictions on their lists. There is a lag time between that change and the time when others can or cannot (depending on the change in permissions) access that list. Doing ListSearch requests within 24 hours of a change in access permissions.
Relevancy rank does not work with blended searches. Relevancy rank generally corresponds with sales rank. Currently, the relevancy rank using ItemSearch blended searches yields inaccurate results. ItemSearch requests where the SearchIndex is "Blended" and the sort parameter is relevancy.
Updating the availability status of some items takes exceptionally long. There is a lag time incurred for the availability status of an item to be updated. For a few items in each Search Index, however, those lag times are exceptionally long.  These lag times account for inaccurate availability information, even when the ItemSearch parameter, Availability, is set to "Available." To check the true availability of an item, use the Offers Response Group. If an offer is returned for an item, it is truly available. Requests that list the availability of items in the response.
GZIP functionality not working. XML responses are not GZIP'ed, even if the proper Accept-Encoding header is sent with the request. Requests that stipulate a GZIP'ed response.
The total number of pages returned from a search request decreases as you page through the results. To optimize search results, grouping of similar items is not done until the items are viewed. When the items are viewed and the grouping occurs, the page count shrinks. Applications or web sites that make use of the TotalPages element.
Relevancy score values are sometimes unexpected. Relevancy scores are, in part, determined by the number of occurrences of a word. This algorithm can sometimes lead to unexpected results. For example, while you might expect "laptop" to be most relevant to Computers category, the relevancy score is higher in "Sporting Goods" because the word "laptop" occurs there more often, for example, in phrases such as "laptop bag." ItemSearch requests sorted by relevancy.
In cart operations, validation is not performed on ListItemId. Validation is not performed in some cart operations. It is possible, for example, for the ListItemId not to correspond to the ASIN. Adding items to cart from a list using a ListItemId.
MerchantId does not always filter search results. MerchantId is not used in books, music, classical, video, wireless, DVD, communities, wishlists, Target, and all international stores. MerchantId cannot be used as a filter for any of these groups. Doing so might lead to unexpected results, such as items being sold by some merchant other than the one specified by the MerchantId. ItemSearch requests that use MerchantId.
SellerLookup sometimes does not return the Seller Name or correct location. Results from the SellerLookup operation may not return the SellerName element or return the correct Location values. Applications or web sites that use the SellerName or Location values.
ItemLookup does not return some editorial reviews. ItemLookup only returns the editorial reviews written by Amazon.com. Editorial reviews recorded by another web site cannot be included in the reviews returned by ItemLookup.
Feature elements are missing from ItemAttributes. ECS 4.0 does not return the Feature element, which is returned by ECS 3.0, for ItemAttributes. Applications or web sites that use the 3.0 Feature element.
Items returned using the PCHardware search index may not be hardware. Using the PCHardware search index with the ItemSearch operation returns non-hardware items.  
ItemSearch Power requests do not return accurate results for specific dates. ItemSearch responses may be incorrect when the request specifies a specific day. Using date ranges returns expected results. ItemSearch Power requests that specify specific dates.
WishList is returned even when ListType=WeddingRegistry. In ListLookup, when you set ListType to “WeddingRegistry,” the operation returns both a WeddingRegistry and, unexpectedly, a WishList. Both lists are based on the same ListId. When you set ListType to “WishList,” ListLookup only returns a WishList, which is correct. ListLookup requests that set ListType to "WeddingRegistry."
Customer Reviews are not in sync with Amazon's retail website. Customer Reviews returned by search operations may not be in sync with the reviews on Amazon's retail website. Applications that return customer reviews.
ReleaseDate not returned for some items. Some items, such as DVDs, do not have release dates. Sorting by release date, then, sometimes generates spurious results. Applications or web sites that use the ReleaseDate element.

Phrases in quotes used as values for the Keywords parameter in ItemSearch requests do not perform as expected.

Quoted phrases in the Keywords field for ItemSearch are not accepted as a whole phrase. Instead, they are broken up into individual terms and results are returned for subsets of the phrase. For example, the parameter Keywords="the last time" should only return results for "the last time", rather than "the", "last" or "time". ItemSearch requests that use phrases for Keyword values. Instead, use the TextStream parameter.
Default input content encoding is not UTF-8. JP is the only locale that correctly takes UTF8 input. All other locales use LATIN1. Applications dependent on UTF8.
ItemSearch using TextStream may not work for all search indices.

Some search indices, such as, Tools, Software, and Jewelry, do not work in ItemSearch requests using the TextStream parameter.

Applications or web sites that use the TextStream parameter.

 

To receive notification of future releases automatically, go to http://developer.amazonwebservices.com/connect/ann.jspa?annID=64.

Related Documents

©2014, Amazon Web Services, Inc. or its affiliates. All rights reserved.