API Documentation #42
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
campaign-blocker
consider soon
Content
dependencies
Epic
good first issue
hacktoberfest
help wanted
icebox
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbry.tech#42
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is the epic issue to collect all changes required to have API documentation work inside of lbry.tech.
After some discussion, there is now some uncertainty as to whether OpenAPI/Swagger is the right solution.
Required properties:
Ideal properties:
Other considerations:
Consider https://github.com/lord/slate, it produces similar looking docs to stripe. Slate appears to be a pretty popular solution: https://github.com/lord/slate/wiki/Slate-in-the-Wild
suggesting a more complete format (example below):
Structure
Example
I know I'm an outsider but I've begun taking a crack at a JS api binding so this convo is relevant for me.
Might want to take a look at jrgen; there's a decent amount of prior work there (.md, .html, gitbook support, plus code-gen), the schema is not dissimilar from what you've got above, and it doesn't barf on adding extra properties (examples). I just did a quick sanity check porting the example given by @lyoshenka and ran into no trouble. Here's what it looks like:
I'm probably going to use it for code-gen on my side to get started with a Javascript binding; which means I'll end up writing a schema file as part of work on that client. Happy to be advised as to the most useful thing to do with it :)
@rynomad thanks for the suggestion! @lyoshenka / @eukreign any thoughts on the above?
I don't have additional thoughts. @NetOperatorWibby is most affected by this (he has to convert the JSON into a new HTML document and/or use jrgen as suggested by @rynomad) so it's up to him.
You’re creating the parser @eukreign, all I’m doing is parsing a JSON file. So, it’s up to you.
@NetOperatorWibby Okay, this is easy: are you planning to use jrgen?
If no, then I'll stick to a combination of my original JSON and what @lyoshenka suggested.
If yes, then I'll make it compatible with jrgen.
@eukreign Nope, all I should be doing is parsing a file. The generator should take care of everything else.
I really like the jrgen suggestion. I would like to go that way for lbrycrd API docs ( https://github.com/lbryio/lbrycrd/issues/131 ).
@eukreign @BrannonKing whichever format you choose, please document the final structure of the generated file