Page MenuHomeSoftware Heritage

Http API to access the SWH vault

Authored by qcampos on Aug 24 2016, 1:01 PM.



This API currently only concern the directories as it uses the first draft of the cooker.

Ref T532
Depends on D102

Diff Detail

rDSTO Storage manager
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

qcampos retitled this revision from to Http API to access the SWH vault.
qcampos updated this object.
qcampos edited the test plan for this revision. (Show Details)
qcampos added a task: T532: Vault API.
ardumont added a reviewer: ardumont.
ardumont added a subscriber: ardumont.

If you have the time to do the small refactoring about the api redundancy, please do it.

Otherwise, this seems good to go so accepted.


I see those same (or equivalent) snippets in, swh.objstorage.api.client.RemoteObjStorage.

Can't we factorize those methods (url, post, get seems new) say in a base class somewhere?
swh.objstorage seems appropriate for this since swh-storage already depends on it.


Maybe explicit that this is to be called when the directory is cooked.
By updating the function name for example, get_cooked_directory.

This revision is now accepted and ready to land.Aug 29 2016, 1:07 PM
qcampos edited edge metadata.
qcampos marked an inline comment as done.

Rename method to make it more explicit

get_directory was misleading as in only concern cooked directory.
As the endpoint is already GET/POST-specific, this enlightment is needed.

This revision now requires review to proceed.Sep 12 2016, 11:47 AM
ardumont edited edge metadata.
ardumont added inline comments.

ah yes, nice catch, bytes won't pass with celery without adding some extra converters ^^

This revision is now accepted and ready to land.Sep 12 2016, 11:56 AM
This revision was automatically updated to reflect the committed changes.