Skip to content
Snippets Groups Projects

Add a link to our terms of use in API response headers

1 unresolved thread

As a small hint for users of our rest API, let’s add a X-Terms-of-Use header to the responses. It contains the URL of the “Terms of use for bulk access” web page.

Merge request reports

Members who can merge are allowed to add commits.

Pipeline #6249 passed

Pipeline passed for 2317849d on lunar:add-tos-in-response-header

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Jenkins job DWAPPS/gitlab-builds #517 succeeded .
    See Console Output and Coverage Report for more details.

  • added 1 commit

    • 2317849d - Add a link to our terms of use in API response headers

    Compare with previous version

  • Jérémy Bobbio (Lunar) resolved all threads

    resolved all threads

  • Antoine Lambert approved this merge request

    approved this merge request

  • Jenkins job DWAPPS/gitlab-builds #518 succeeded .
    See Console Output and Coverage Report for more details.

  • Jenkins job DWAPPS/gitlab-builds #519 succeeded .
    See Console Output and Coverage Report for more details.

    • This is a bit surprising to me; Is this something that other APIs do? Do we really expect the people who we want to see this to see it?

    • I don’t know if other APIs do this. My bet is that people who explore the API are likely to use tools displaying response headers. I saw this as a gentle nudge if they haven’t yet looked at the ToS yet.

    • Our own HTML rendering of API responses doesn't show the value of response headers, so this will leave the terms of use hidden as one of many links in the footer for these users, which I expect to be a good fraction of people who explore our API.

      https://archive.softwareheritage.org/api/ doesn't have a direct reference to our terms of use either (nor a disclaimer that the API isn't appropriate for scraping / bulk access).

    • Please register or sign in to reply
  • not a fan of the idea of using non standard http headers for this either, and I agree a link to the terms of use is missing, maybe we could add it here:

    image

  • Please register or sign in to reply
    Loading