[ANNOUNCE] findAllUserCharges - Windowing deadline extended, meta resource added

[Chris Dary]

Hi everyone,

( A brief background for those not following along: The API Resource findAllUserCharges is being modified to require time windows to increase speed of response. More information here: https://groups.google.com/forum/#!topic/etsy-api-v2/MUx0MJhRvTU )

As promised, we've added a new bill charge meta resource - getUserChargesMetadata - which provides you with total charge counts, as well as the earliest and most recent bill charge from this user. This should be useful for sanity checking and synchronization. More information in the documentation here: http://www.etsy.com/developers/documentation/reference/billcharge#section_getuserchargesmetadata

In addition, we're extending the deadline for findAllUserCharges to require time windows to help make use of these changes. We're adding an additional two weeks to the deadline: you'll now want to be switched over to the new windowing syntax by August 8th, 2012. We'll be deploying the final change which will cause the older syntax to break on that date.

Thanks again for the feedback on this, everyone. We hope this is helpful. Thanks also to Paul Wright for getting this to the finish line on our end!

Chris Dary

API Lead

[Katrina Owen]

On Mon, Jul 23, 2012 at 1:59 PM, Chris Dary <cd...@etsy.com> wrote:
> As promised, we've added a new bill charge meta resource -
> getUserChargesMetadata - which provides you with total charge counts, as
> well as the earliest and most recent bill charge from this user

Sweet! Thank you for this.

Cheers,
Katrina

[Nicole (Craftybase)]

Thanks so much for listening to our concerns and for extending the deadline :)

[MON KEY]

On Jul 23, 7:59 am, Chris Dary <cd...@etsy.com> wrote:

>
> As promised, we've added a new bill charge meta resource -
> getUserChargesMetadata - which provides you with total charge counts, as
> well as the earliest and most recent bill charge from this user. This
> should be useful for sanity checking and synchronization. More information

> in the documentation here:http://www.etsy.com/developers/documentation/reference/billcharge#sec...
>

Please verify that the documentation for the new
getUserChargesMetadata resource is correct.
Most doucmentation/reference sections have the format:

Overview
...
Auxillary Info (optional)
...
Fields
...
Associations
...
Methods
...

This presentation format is not present for the current BillCharge
reference:
http://www.etsy.com/developers/documentation/reference/billcharge

It has the following format:

Overview
...
Auxillary Info
...
getUserChargesMetadata
...
Fields
...
Associations
...
Methods
...

Shouldn't the doc for getUserChargesMetadata apear beneath the Methods
heading?

Also, the JSON returned for getMethodTable indicates it is of type
"Dict".
Vis a vis the Etsy API what is a "Dict" type?
If the intent is to add a new "Dict" type please document it as well.

[Chris Dary]

Hi there,

You're right, the documentation is a bit out of order right now. This was pushed out with some haste so that you all could start making use before the deadline got any closer. It's a result of a known limitation within our documentation generation system that we're looking at making a bit more flexible.

In this context, Dict just means a simple associative array. Since this resource is purely metadata, no special functionality needs to be wrapped with it. You're right though, we should either document this or specify a simple type for it. Thanks for the feedback.

-Chris

[MON KEY]

On Monday, July 23, 2012 2:03:11 PM UTC-4, Chris Dary wrote:

Hi there,

You're right, the documentation is a bit out of order right now.

Yes, this is troublesome because without an alternative mechanism for interrogating the fields, their types, and permission scopes for the representation of a resource my only recourse for sanely modelling the canonical form that a resources representation may take is the documentation.
IWBN if there were an Etsy API method for fetching this for all of the Etsy API representations, e.g. something equivalent to "getMethodTable" for ApiMethod  or "describeOccasionEnum", "describeRecipientEnum", "describeWhenMadeEnum, "describeWhoMadeEnum" for DataType.

In this context, Dict just means a simple associative array.

OK, thanks. So is it expected that a Dict will continue to be exposed as a representation of resource as reflected by the case convention?
 

Since this resource is purely metadata, no special functionality needs to be wrapped with it.

No special functionality needed on your end maybe :)

You're right though, we should either document this or specify a simple type for it. Thanks for the feedback.

Please understand, my concern is not simply about the paucity of documentation for a newly introduce feature but also w/r/t the documentation acting as the only holistic reference as to how we are expected to request and respond.

[Chris Dary]

Hi List,

As slated, this change is now live. Our graphs show that nearly all of you have made the switch already, so this shouldn't impact many of you—thanks everyone!

-Chris