Tip:
Highlight text to annotate it
X
MALE SPEAKER: Shanghai GDG is a very
interesting developer community.
FEMALE SPEAKER: I'm glad somebody
has asked this question.
MALE SPEAKER: This is where the magic happens.
FEMALE SPEAKER: This is primarily a question and
answer show.
So if any of you out there would like to ask questions.
AMANDA SURYA: All right.
Well, welcome everybody to our session on Content API for
Shopping office hour.
I am Amanda Surya.
I'm a Developer Relations Manager for
Google Commerce products.
DANNY HERMES: And I'm Danny Hermes, as you all may already
know, Developer Programs Engineer on Google Shopping.
So thanks for joining us today.
Amanda's got some questions that we're going to be going
over covering some things that people have been asking on the
forum and also some recent developments in Google
Shopping as we go forward.
And if people have questions who are viewing this remotely,
please feel free to add them to our Moderator queue.
So--
AMANDA SURYA: All right.
So there's this question in our forum recently about the
benefits of switching from existing data feed
infrastructure to using the content API for shopping.
Can you talk more about that?
DANNY HERMES: Yeah.
So first I wanted to say we did a video last October.
And I mentioned this in the forum as well.
And you can see the screenshare of the YouTube
video here that I'm sharing in the Hangout.
And we compare and contrast feeds in the content API and
kind of cut out firm use cases where you might actually be
more interested in the content API.
And some of them were actually expounded upon by Andrew from
Zazzle in the forum.
And he actually explained what they used to do, what they do
now, what some of the downfalls are, and how the
pros outweigh the cons.
So this actually speaks directly to our best practices
because the best practices kind of point to why you might
want to make the switch, or why maybe you might not make
the switch, or why it might not be necessary for you to
make the switch.
So I have it pulled up here, the very first part of the
best practices page lists when to use the
content API for shopping.
So--
AMANDA SURYA: So when should we use it?
DANNY HERMES: Exactly.
So there are sort of four use cases.
The first use case obviously is when you want to be
programmatic, when you don't actually want to have human
interaction or you don't actually want to be uploading
something by hand.
AMANDA SURYA: If you have a lot of--
DANNY HERMES: Right.
Or maybe you just have an automated system and you want
it to stay automated, right?
Obviously, there are ways to do this
already with feeds files.
But it requires manually creating spreadsheets, or
comma-separated value sheets, or some other column-formatted
feed, and then using FTP to programmatically upload it.
And then, of course, there are all these other issues.
Another nice-to-have feature, which we certainly emphasize
in that video and we emphasize here as well, is the fact that
you get immediate feedback back from the API rather than
when you're using feeds.
Feedback is asynchronous.
And it comes in an email summary, whereas feedback from
the API is immediate, on the order of half a second.
And it is for every single item in your particular
request that's being given feedback.
And one of the main things that Andrew emphasized and
that a lot of people making the switch, the original
poster was asking-- they said they had a
million and a half products.
Well, if you're sending feeds, and even if you're sending
them once an hour and your feeds are getting processed in
that hour, it's still an hour out of date for some of the
products that were updated at the very beginning.
So what they said at Zazzle was they actually had some
merchants who were upset by the
infrequency of these updates.
And by using the content API, they're actually able to get
these updates in almost immediately rather than
waiting for the feed to get processed and then the data to
get pushed back through.
And a final use case, which I'll also touch on briefly,
was if you have multiple subaccounts.
And going to the merchant center and clicking through
all these subaccounts is infeasible.
So even if you had multiple people working on it, once you
exceed probably 10, 20 subaccounts, it's not really
very possible for human beings to go in and make sure
particular changes are actually as desired by the
client or the end user that you're actually managing
product data for.
So the second part of this document is actually the best
practices themselves, how to actually go ahead and use the
content API.
And the very first one says don't use the API as
you would use feeds.
So, obviously, this is sort of like if you're on our side of
the fence, don't straddle the fence type of recommendation.
But it actually shines some light on why you might want to
make the switch.
in the feeds world, like I previously mentioned, you have
to send your entire feed.
So you have to send the things that don't change at all.
You have to send all the new things.
You have to send the updates.
And you have to make sure the things you're
deleting aren't in there.
Well, with the content API you don't have to do that.
So all you have to do with the content
API is send the changes.
And that's about all I'm going to say about best practices.
Or actually, the fourth bullet point in how to use the
content API for shopping is a caveat that Andrew noted in
his response, which is actually a
pretty important caveat.
So by default, products, whether they're inserted via
feeds or via the content API, they can't expire in
more than 30 days.
So the longest expiration you can have for a product that
you insert or update is 30 days.
And so if you're using the content API, you're not
actually sending updates for products that don't change.
Well, if for some reason part of your inventory hasn't
changed in 30 days, on day 31 if you don't send any updates,
that product will disappear and eventually be garbage
collected and actually be out of your inventory rather than
showing as expired in your inventory.
So it's actually important when you make the switch to
change this frame of mind from I need to send all my product
data all the time to I need to send my updates
whenever they happen.
And I also need to make sure that my infrequently updating
products don't get obsoleted via an expiration date.
So it was a great question.
And the poster also had another question, which we're
actually going to jump right to.
So--
AMANDA SURYA: Right.
So let's switch gear a little bit.
There is another question, different question about our
Java sample code, and what we currently have, what we
currently provide, for a developer who's using Java and
wants to use the content API for shopping, and what's our
plan forward in terms of resources.
DANNY HERMES: Sure.
So people who look at our Developer Resources in our
documentation will notice that there's a Java Developer's
Guide, a .NET Developer's Guide, a Python Developer's
Guide, and PHP Developer's Guide.
And people who know all four languages might look at the
Java Developer's Guide and think, we don't like Java
developers.
But that's not the case.
We're a small team.
It's something we're aware of that is a bit lagging behind
the other three.
But our sample is certainly a workable starting point for
actual working Java code.
So the PHP library is sort of a special case.
We manage our own small PHP library just for shopping.
But for .NET and Python, there are large gdata libraries.
So Python is gdata-python-client.
And for .NET it's google-gdata.
.NET must have gotten there first for grabbing that name.
But for Java, we don't really have any equivalent library
that we recommend for merchants.
However, one exists.
Just like there's a gdata-python-client, there's a
gdata-java-client.
And for actual gdata APIs, other than the content API for
shopping that are implemented there, the way the code is
implemented-- for example, the way the HTTP requests are
formed and sent--
it uses an external library that
obviously works with HTTP.
Similarly, for doing authentication like client
login, OAuth, AuthSub, OAuth 1.0, or 2.0, that is, it uses
a JAR coming from a different Google client library.
And this is something that the original poster, Rich,
actually asked about.
So first I want to say that all these dependencies in the
sample are actually consistent with what the
gdata-java-client requires.
But the fact that we have sort of hand-held data classes is
just a symptom of us being a bit behind.
So we certainly are working right now actively on getting
support into the library and actually updating the section
in the Developer's Guide about Java.
A few more things that I want to say about this.
So first of all, the original poster asked about the
difference between this gdata library
and these new libraries.
And he quoted some statement in the google-api-java-client
library about how Google is updating to
discovery-based APIs.
And so I actually talk a bit about all of this in a video
that I recorded.
We actually have a playlist of all of our videos for content
API developers, and you should see that
flashing across your screen.
This specific video where I talk about Auth and OAuth 2.0
and some of these other mechanisms is called Getting
Started with Google Shopping.
And there should be a short link to the YouTube video
flashing across your screen for that as well.
I actually go through the Auth flow in Python around the
18-minute mark.
It takes about 22 minutes.
AMANDA SURYA: Right.
DANNY HERMES: So the difference between gdata APIs
and these other APIs is just sort of the newer Google APIs
are exactly that.
They're newer.
So gdata uses sort of an older framework.
And we certainly don't have any estimations on a timeline
or anything like that.
But for the time being, the content
API is a gdata library.
So that is the target for developers.
You shouldn't be targeting this new library that exists,
but it's not actually intended for gdata APIs.
So you should actually be targeting
what's in the sample.
And finally, the last question about why OAuth?
Why not client login?
Why not some of these other ones?
So there are a few things to say about that.
But most importantly, we announced on April 20, as you
may be able to see in the screen I'm sharing, that along
with some other older Google APIs, the actual Auth APIs ,
other than OAuth 2.0, are being deprecated.
So client login, AuthSub and OAuth 1.0 are all being
deprecated.
And I believe April 20, 2015 is when
they're officially retired.
But between now and then, they are to be considered
deprecated.
And I would highly recommend against developing
with them in mind.
Rather, develop with OAuth 2.0 in mind.
AMANDA SURYA: Right.
DANNY HERMES: And this is something we certainly get
plenty of questions about.
And we're happy to go more in depth about if people still
aren't understanding things.
AMANDA SURYA: Yeah.
And definitely feel free post your additional questions
around OAuth 2.0 the forum as well--
DANNY HERMES: Yeah.
AMANDA SURYA: --if you have concerns about that.
All right.
So another question that we recently got is about
destination.
DANNY HERMES: Yep.
AMANDA SURYA: So in the spec, there's three supported
destination values--
product search, product ads, commerce search.
Can you talk more about that?
There are other valid values as well.
What are those and how can people use it?
DANNY HERMES: Right.
So this question from Thor--
love the name--
was a good question.
So he was asking, I'm seeing some other values like
Shopping API and Affiliate Network.
And I'm wondering why these aren't in the documentation.
So these attributes are not valid for every account.
So that's kind of why we don't include them in our
documentation.
So some people who also have used the search API for
shopping may be familiar with the Google Affiliate Network.
And so product data, you can actually make valid for the
destination Google Affiliate Network if you're actually in
the Google Affiliate Network.
And by the same token, if you elect, your product data can
also be consumed by all users of the shopping API--
excuse me, the search API for shopping.
And that's why the shopping API destination is a possible
value as well.
But for the time being, products ads, products search,
and commerce search are these valid destinations.
So a bit more about how to use destinations.
So Thor was having some issues where he was getting errors
that he didn't really understand why.
So if no destinations are sent, then by default we say
you have to require at least one destination as valid for
your product data.
And so the default value for a required destination is
product search.
And the way required destinations work is if your
product doesn't validate for that destination, then your
response will be rejected.
And you'll get a failure.
So your product data will never get uploaded or
inserted, whatever term you're looking to use.
But whatever it is, it won't end up in the database
corresponding to your merchant center account.
So what Thor was doing was he was asking for validate
destination for product search with nothing else.
So this default value required for product search was also
being inserted.
So the API doesn't allow you to validate and require the
same destination.
So that's why his requests were getting rejected.
And for those who aren't familiar, what it means to
validate rather than required--
so I mentioned this term "validate" when I was talking
about required.
So are they the same?
Are they different?
Well, required will go ahead and validate that destination.
And if it fails validation, it will reject the request.
On the other hand, validate destination will go ahead, and
it'll validate the destination in question.
But rather than rejecting the request if the actual product
data is valid for some other destination, it won't get
inserted for the destination that
you asked to be validated.
But you will get the errors back for why it wasn't valid.
So it's a way for people who maybe aren't as strict about a
particular destination, maybe shopping API, for example.
But it allows for them to actually attempt to get the
data put in there and then find out why, for some reason,
the given product or set of products weren't valid.
And then, of course, there's this third value which Thor
didn't ask about but "excluded destination." And that's
exactly what it sounds like.
You don't want your product data surfacing in that
destination.
And it just won't be validated.
It won't be inserted.
And then, there was sort of a third question that Thor had.
And that was, given the move from Google Product Search to
Google Shopping, what's going to happen with product ads and
product search, and where are we going with that?
So that's something I want people to know that we're
thinking about.
But we don't have anything to say at this time.
But it's certainly something that we're aware of.
And I'm going to--
AMANDA SURYA: Speaking of that, there's actually a
series of webinars that are Google Shopping, Product
Marketing Managers, and
Partnership Teams put together.
And if you're wondering about what it means, how to turn on
product listing apps on your product listings, these series
or webinars, we highly recommend you to review them.
It's a great resource to get started at and also paint the
bigger picture in terms of where Google Shopping is
moving forward.
And you can view the series in the YouTube channel.
Or you can follow John Venverloh, who is in the
partnership team.
And he basically, on his G+ page, lists all the series of
webinars that he and his team has done.
And it's a great resource, again, for some of you who
want to get a better understanding of the overall
picture and interim materials to Google Shopping.
DANNY HERMES: Yep.
And we'll be posting some links in that YouTube video
after the fact.
So if you're actually watching the YouTube video after the
fact, the link should be in the description.
We'll link to John's page and the specific posts that he has
linked as well as to the channel where you can find
some of these videos.
AMANDA SURYA: All right.
So those are pretty much the questions that
we've seen in the forum.
And there are no questions in the Google Moderator.
So I think we're off the hook here.
DANNY HERMES: All righty.
AMANDA SURYA: And for those of you listening in, thank you
for joining us.
And if you want to learn more about the content API for
shopping as well as our other commerce APIs, visit
developers.google.com/commerce and all the information and
documentation should be there.
And we're doing this biweekly, so hope to
see you in two weeks.
DANNY HERMES: How many days are in August?
30 or 31?
AMANDA SURYA: 31?
DANNY HERMES: I think there's 31.
So September 13th is 14 days from now.
All righty.
Thanks, everyone.
AMANDA SURYA: All right.
DANNY HERMES: And have a nice day.
AMANDA SURYA: Thank you.
[MUSIC PLAYING]