Create get vulnerability details API

[ZhangChen199102]

Issue: #2152

This PR introduces a new GET vulnerability details API

[ZhangChen199102]

Moving these functions to utils.py so they can be used by both of api_handlers and frontend_handlers.

[ZhangChen199102]

Create a new app for API

[another-rex]

Unless I'm misunderstanding the goal, rather than putting API code in the frontend as well, I think we can just put a link to the GET API endpoint on the page, or add a new handler to redirect requests ending in .json to the API endpoint.
https://google.github.io/osv.dev/get-v1-vulns/

E.g. https://api.osv.dev/v1/vulns/CVE-2023-45802

[andrewpollock]

or add a new handler to redirect requests ending in .json to the API endpoint.

That was my understanding of the easiest way forward based on #2152 (comment)

[ZhangChen199102]

So this time I just added a JSON Data field, with a GET vulnerability details link on the vulnerability details page:

[andrewpollock]

So this time I just added a JSON Data field

That's cool, but doesn't address the UX intention behind #2152 (as I understand it).

Today, there's a convenience redirect where:
https://OSV.dev/GHSA-75mx-chcf-2q32 redirects to https://osv.dev/vulnerability/GHSA-75mx-chcf-2q32

An additional convenience redirect would be for:
https://OSV.dev/GHSA-75mx-chcf-2q32.json to redirect to https://api.osv.dev/v1/vulns/GHSA-75mx-chcf-2q32

Without having tried this, I think a variation on:

osv.dev/gcp/appengine/frontend_handlers.py

Lines 230 to 242 in 7428293

	@blueprint.route('/<potential_vuln_id>')
	def vulnerability_redirector(potential_vuln_id):
	"""Convenience redirector for /VULN-ID to /vulnerability/VULN-ID."""
	if not _VALID_VULN_ID.match(potential_vuln_id):
	abort(404)
	return None
	vuln = osv_get_by_id(potential_vuln_id)
	if vuln:
	return redirect(f'/vulnerability/{potential_vuln_id}')
	abort(404)
	return None

would accomplish this redirection:

• support .json in the URL handler
• if the vulnerability ID exists, redirect to the existing JSON API endpoint, per my example above

[andrewpollock]

This LGTM, have you been able to do any testing to confirm it works as intended?
FYI, I wasn't averse to highlighting the availability of the API from the individual vulnerability pages on the website in addition to this. Feel free to reinstate that.

[another-rex]

LGTM! One minor note would be this will always redirect to the production API, even when running on test.osv.dev. Not sure if there's an easy fix for that or not, if not I think that behaviour is fine.

[another-rex]

minor nit: can you change the if vuln: to if not vuln: to have the final return statement be the redirect, and the if branches be the aborts.

[ZhangChen199102]

This LGTM, have you been able to do any testing to confirm it works as intended?

Yes, I've tested http://127.0.0.1:8000/vulnerability/GHSA-vw63-824v-qf2j.json and http://127.0.0.1:8000/GHSA-vw63-824v-qf2j.json on local, and both redirects me to https://api.test.osv.dev/v1/vulns/GHSA-vw63-824v-qf2j

[ZhangChen199102]

One minor note would be this will always redirect to the production API, even when running on test.osv.dev. Not sure if there's an easy fix for that or not, if not I think that behaviour is fine.

Thanks, I've updated this and now it will redirect to api.test.osv.dev in local and test environment, and api.osv.dev for prod.