Data List for Individual Work Page

[riazaia]

Individual Work Page

(https://archiveofourown.org/works/{id})

• [x] url
• [x] id
• [x] rating
• [x] warnings
• [x] category
• [x] fandom
• [x] relationship
• [x] characters
• [x] additional tags
• [x] language
• [ ] series number
• [ ] series name
• [ ] series id
• [ ] collections
• [x] published date
• [x] updated date
• [x] completion status
• [x] words
• [x] posted chapters
• [x] expected chapter
• [x] completed
• [x] comment number
• [x] kudos
• [x] bookmarks
• [x] hits
• [x] title
• [x] author
• [x] author username
• [ ] summary
• [ ] pre-work notes
• [ ] images
• [ ] chapter number
• [ ] chapter title
• [ ] chapter notes
• [ ] chapter text
• [ ] chapter words
• [ ] work text
• [ ] post-work notes
• [ ] locked status
• [ ] inspired by work by author
• [ ] gifted to
• [ ] works inspired by this one
• [ ] translations
• [ ] kudos list
• [ ] comments

[cyrusae]

• [ ] detect restricted work

(Is there a way to do that first and have it terminate all the other ones? Maybe nesting the getThing constants?)

Added ability to check for restricted status on its own ( #14 ), unsure if it should be folded into works page instead but if nothing else hopefully is a resource

[enigmalea]

series url author url

• also fair warning that series, author, and collection will have to cover a work that’s in MULTIPLE series author and collection.

FWIW, I’d rather have things like notes, summary, text, etc return the full html block (not strip out any formatting tags) and then the user can sanitize or reformat however they need. (For example for Archivist, I’d like to be able to take the html formatting the AO3 user has added and transform it to markdown, but I can’t do that if it’s been sanitized ahead of time).

[cyrusae]

Hopefully this isn’t off topic, but I’ve been meaning to add the option for plaintext bio separate from formatted bio to the user utils and wonder if there’s merit in doing the same here? I agree that html is the priority, I was just thinking there wasn’t any reason I know of not to put that flexibility in. On Feb 11, 2022, 13:51 -0800, Amber @.***>, wrote:

series url author url

• also fair warning that series, author, and collection will have to cover a work that’s in MULTIPLE series author and collection.

FWIW, I’d rather have things like notes, summary, text, etc return the full html block (not strip out any formatting tags) and then the user can sanitize or reformat however they need. (For example for Archivist, I’d like to be able to take the html formatting the AO3 user has added and transform it to markdown, but I can’t do that if it’s been sanitized ahead of time). — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: @.***>

[enigmalea]

Hmmm... I think there's probably merit in it. Maybe there's something worth doing it as plain text, html, or markdown within the API as those are the main ways for text data to be provided on the web now.

@essential-randomness what are your thoughts about large text blocks and formatting?

[essential-randomness]

I would personally approve of us giving people a nice interface to extract the data in markdown, plain text or HTML for a couple reasons:

1. I would assume the average AO3.js end users to not be super technical but more of a fandom hobbyist. We can assume this type of transformation would be beyond their skills, or at least doing it ""the right way"" where they don't give up in frustration a week in would be. So I'm up for doing this legwork for them.
2. There's some libraries that do this that I'm interested in exploring for Boba stuff, and would love the excuse to try them.

Only caveat: we should just return the HTML from AO3 from our API, and then we should provide transformations as utilities. Let's not overload the core library.

[riazaia]

as per #15 you can now get a work url and id