Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bridging ArchiveBox #388

Open
waybackarchiver opened this issue May 4, 2023 · 2 comments
Open

Bridging ArchiveBox #388

waybackarchiver opened this issue May 4, 2023 · 2 comments
Labels
enhancement New feature or request go Pull requests that update Go code

Comments

@waybackarchiver
Copy link
Contributor

ArchiveBox is a powerful open-source web archiving tool that supports a wide range of archive formats, includes an administrative backend, and offers various other features. It performs well in archiving tasks, and Wayback aims to build upon it to provide even richer functionality.

Our plan is to utilize ArchiveBox as an additional backend for requesting archiving through an REST API. Unfortunately, ArchiveBox's API plan has not been implemented yet. To accomplish this particular feature, we will initially implement it by simulating web requests during the early stage. Once ArchiveBox's API plan is completed, we will further migrate to a REST API in a later stage.

@waybackarchiver waybackarchiver added enhancement New feature or request go Pull requests that update Go code labels May 4, 2023
@pirate
Copy link

pirate commented Jun 6, 2023

Excited to see this! It adds some logs to the fire under my butt to get that REST API pushed out 😆

In the meantime you can go one step further than just mocking out API requests as no-ops. If you're willing to have your REST API stubs call Python API functions imported from archivebox/main.py, then it will work just like it would with the API as long as the archivebox instance is on the same local machine. Then we can swap those local function calls with REST requests without too much difficulty. My plan for the API is to basically expose endpoints to call each main.py function + FastAPI/DRF GET/POST/PATCH/etc. on the models, so it will be almost exactly the same API (each kwarg becomes a POST parameter, stdout instead returned as structured json, etc.).

@waybackarchiver
Copy link
Contributor Author

Thanks for the hints, it opened my mind and gave me new ideas!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request go Pull requests that update Go code
Projects
None yet
Development

No branches or pull requests

2 participants