Brian’s Comments (group member since Mar 30, 2011)

Brian’s comments from the Goodreads Developers group.

By the way, I did some librarian cleanup on the particular examples you gave above that didn't do well on the search API, and it seems to have helped in most cases. Others might take 30 minutes or so for search indexing to catch up. So if you have a number of these and can post them to the librarians' group, we'll probably find that takes care of many of the problem books.

Yes, it should be the app name. I don't see an app by that name, so I'm guessing that the text is not a link (which it should be, and should link to a page revealing what the app is).

You'll get this condition if the developer key has been revoked or if the API developer does not have a URL provided for the app. If you're the owner of the app in question, try adding a URL associated with your developer key.

So I looked into your authorized apps, and it looks like you've got an app created by this user: http://www.goodreads.com/user/show/11..., which kinda looks like you (evil twin? ;) ).

Just provide a URL for the app and it should display properly. Looks like all you're doing is testing things anyway, so should've been pretty clear which app that was. ;)

i am interested, thanks. curious why you're always inserting author into searches. are these searches generated by your users or are you constructing these queries programmatically? have you tried dropping the author from search terms? because, yes, we definitely weight the title more than author.

do any of these look like 'dirty data'?...perhaps low quality books squatting on those exact titles, non-books, or even books that just need to be combined? please post to librarians' group if you're finding any of those conditions.

We've had to put in some authorization to prevent some inappropriate use of our users' review content, so you don't get access to review text by default. So none of the APIs will allow access to those data. It appears some of our documentation may be out of date, apologies.

There certainly are examples where our search isn't returning the book you're expecting. I think you may have to concede that the example you gave us was going to be a difficult one: the title was (I've updated the book's data now that you pointed it out) exactly the search string you gave. We certainly endeavor to improve our search algorithm, but in cases like this, the best recommendation I can give you is to post on the Librarians' Group: http://www.goodreads.com/group/show/2... to request someone clean up a particular book that looks funky (wrong title, misleading title, wrong author, author in title, needs to be combined with other editions, etc.).

Now that a few minutes have passed, my corrections to the book's data seem to have fixed the search you've provided.

I haven't seen this behavior very frequently, but you've found it happening 'often'...could you share some more examples? Are they usually in cases where you provide title and author as the query? See if the librarians can help out on your list, but if all the book data are correct, we'd certainly appreciate if you compiled a list of some examples so we can take a look at how to tweak the search algorithm parameters.

Understand the request and it makes sense, though since the API does support all the functions you need to perform, I think it's unlikely we'll make that change soon. If lots of community support for this builds, we can take it under consideration.

Not sure I get the picture of what your response is. can you give me a snippet of the XML? cause this is what i see for your to-read:

<user_shelf>
<book_count type="integer">26</book_count>
<description nil="true"/>
<display_fields/>
<exclusive_flag type="boolean">true</exclusive_flag>
<featured type="boolean">false</featured>
<id type="integer">...</id>
<name>to-read</name>
<order>a</order>
<per_page type="integer" nil="true"/>
<recommend_for type="boolean">true</recommend_for>
<sort>position</sort>
<sticky type="boolean" nil="true"/>
</user_shelf>

so there's a node for position and a separate one for order. yes, for order, 'a' is ascending, 'd' should be for descending and nil will be default (i would have thought default in our display is ascending, but not sure). i checked in the db as well, and your ordering is definitely set to ascending for to-read there, for what it's worth. not sure why the my books page would be showing it as descending, weird.

as for your currently-reading, yeah, if you haven't specifically set an order on the shelf, then you'll get nil for sort and order...in which case, i believe our UI defaults to date added, ascending. i don't imagine we'll insert those defaults into the response any time soon, but on the other hand, i don't imagine we'll be changing the defaults either, so you could potentially assume those on your end to be in line with the my books page.

that answer everything?

should just be the one IP address you get from DNS lookup right now from your perspective. for right now we're always using the same hostname for API calls. do recognize of course that we might change IPs for whatever reason in the future and won't be giving heads ups.... ;)

Not currently scheduled, but it is in our ticketing system. All I can say with any confidence is probably not in the next month.

Should be released on Monday sometime.

Thanks for the heads up, Ed!

I've submitted a fix for code review, so should be released friday or monday. Thanks for finding this! Should also provide correct 'order' values as well.

Your URL doesn't look quite right...the sample URL I see on the API documentation page is: http://www.goodreads.com/author/list/...

and i get a valid response.

In the link you posted, I see "author_url" in place of the author id, and id= as a url param. Those don't look right. You sure you took that url from the API doc page?

I think the url you might want to try is this one: http://www.goodreads.com/author/list/...

Can you check if you're still having the same problem? We did do a release between when you reported this and right now, so it's possible we fixed it....

Daniel wrote: "I've released a version of my Goodreads Android App optimized for tablets:

https://play.google.com/store/apps/de...

It requires Android 3.2 or higher running on a tablet ..."

release on nook store?...

That is absolutely possible...though you either:

- must be the user who first entered the book (and no one has changed your data afterwards)
- or must be a librarian (anyone can apply, part of the fun is finding out how ;) ). It's enough to have a copy of the book (or a record of a version you had at one point) and enter data from that to update an existing book.

Are you a librarian by any chance? If you are, go to the librarian edits page and you'll see that the data came from Ingram. We can't forward a lot of data we get from them in our API due to our agreement with them. Format is unfortunately among those data.

Our agreements with data providers at times prevent us from sharing book images in our API, even when we can show them on the website and in our own mobile apps. That is unlikely to change. Some images we will eventually get directly from publishers or uploaded by users. Those images we can share images for.

Here's a png version of the login button: http://d2owxupnsl35mn.cloudfront.net/...

I'll add it to those pages, but may not get release till tomorrow.

All the others look to be jpeg or png, right? Let us know if you need anything else.

Actually, yeah, I think it should work if you add a 'topic[folder_id]' parameter. Be sure that the folder is in the group or else you should get errors.

Please let me know if it works and I'll add it to the documentation....

Sweet, thanks for the update, and happy coding! :)