Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #17741

Closed (moved)
Open
Opened Dec 02, 2015 by Israel Leiva@ilv

GetTor RESTful API

One of the deliverables for the current roadmap is to create a RESTful API that could provide useful information for third party apps that want to distribute the links. The API itself should be very simple but with the capability for further improvements. Taking the Github API as the main reference, I think a basic version of the GetTor API should display, at least, the following data (in JSON format):

On "/":

{
    "links": "https://gettor.torproject.org/links/{provider}",
    "mirrors": "https://gettor.torproject.org/mirrors",
    "latest_version": "https://gettor.torproject.org/latest",
}

On "/links":

{
    "provider1": "https://gettor.torproject.org/links/provider1",
    "provider2": "https://gettor.torproject.org/links/provider2",
    "providerN": "https://gettor.torproject.org/links/providerN",
}

On "/links/{provider}":

{
    "linux": {
        "en-US": {
            "32_link": "https://provider/link32-fa",
            "32_link_asc": "https://provider/link32_asc-fa",
            "32_sha": "sha32",
            "64_link": "https://provider/link64-fa",
            "64_link_asc": "https://provider/link64_asc-fa",
            "64_sha": "sha64",
        },
        "fa": {
            "32_link": "https://provider/link32-fa",
            "32_link_asc": "https://provider/link32_asc-fa",
            "32_sha": "sha32",
            "64_link": "https://provider/link64-fa",
            "64_link_asc": "https://provider/link64_asc-fa",
            "64_sha": "sha64",
        }
    },
    (...and so on for the other OS)    
}

On "/latest":

{
    "stable": "5.0.4",
    "alpha": "5.5a4",
}

I think "/mirrors" needs a little bit of discussion, specially for defining the filtering. I see two possible filters, the protocol: http, https, rsync, ftp, etc., or the region: US, UA, FR, etc. Thoughts?

With respect to technical details, I have experience doing similar stuff with Tornado, so I suggest we use Nginx + [Cyclone http://cyclone.io/], "a web server framework for Python that implements the Tornado API as a Twisted protocol". This was recommended and used in [Erebus http://github.com/erebus/erebus], one of the Summer of Privacy projects.

So, let's discuss this! Is the proposed format consistent? What other data should we display? Are you OK with using Cyclone? How could we get an SSL certificate for gettor.tpo?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#17741