Currently when using the json API, you have to send a POST request, parse the json response, then return the url from the json response. I would like to be able to directly send a GET request to the API and get redirected to the url, for cases where you need a direct URL to the file such as Discord bots etc.
Additional Context
For compatibility of other things that use direct links (such as Discord bots etc), this needs to be supported.
I would like to be able to use it like this example, but anything else is appreciated as well:
Originally created by @SmilerRyan on GitHub (Sep 1, 2024).
Original GitHub issue: https://github.com/imputnet/cobalt/issues/708
### New API: /api/url
Currently when using the json API, you have to send a POST request, parse the json response, then return the url from the json response. I would like to be able to directly send a GET request to the API and get redirected to the url, for cases where you need a direct URL to the file such as Discord bots etc.
### Additional Context
For compatibility of other things that use direct links (such as Discord bots etc), this needs to be supported.
I would like to be able to use it like this example, but anything else is appreciated as well:
https://api.cobalt.tools/api/url?aFormat=best&isAudioOnly=true&url=https://youtu.be/wcT7zgL6gug
I posted 2 issues since whilst both feel like they are needed for me, they are both different things.
One being to accept GET parameters instead of just POST parameters, and the other to have an endpoint that redirects to a video.
i dont think thats a good design
How would prefer to do this?
My initial thought before deciding on a different endpoint was an extra json such as "redirectToUrl": true.
If it exists to redirect instead of showing the json, but it feels more right to have a different endpoint to expect a url rather than json (url only at /api/url instead of /api/json so it's less misleading).
<!-- gh-comment-id:2323530478 -->
@SmilerRyan commented on GitHub (Sep 1, 2024):
> why did you make 2 issues related to 1 thing
I posted 2 issues since whilst both feel like they are needed for me, they are both different things.
One being to accept GET parameters instead of just POST parameters, and the other to have an endpoint that redirects to a video.
> i dont think thats a good design
How would prefer to do this?
My initial thought before deciding on a different endpoint was an extra json such as ``"redirectToUrl": true``.
If it exists to redirect instead of showing the json, but it feels more right to have a different endpoint to expect a url rather than json (url only at ``/api/url`` instead of ``/api/json`` so it's less misleading).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @SmilerRyan on GitHub (Sep 1, 2024).
Original GitHub issue: https://github.com/imputnet/cobalt/issues/708
New API: /api/url
Currently when using the json API, you have to send a POST request, parse the json response, then return the url from the json response. I would like to be able to directly send a GET request to the API and get redirected to the url, for cases where you need a direct URL to the file such as Discord bots etc.
Additional Context
For compatibility of other things that use direct links (such as Discord bots etc), this needs to be supported.
I would like to be able to use it like this example, but anything else is appreciated as well:
https://api.cobalt.tools/api/url?aFormat=best&isAudioOnly=true&url=https://youtu.be/wcT7zgL6gug
@lostdusty commented on GitHub (Sep 1, 2024):
i dont think thats a good design
@KwiatekMiki commented on GitHub (Sep 1, 2024):
why did you make 2 issues related to 1 thing
@SmilerRyan commented on GitHub (Sep 1, 2024):
I posted 2 issues since whilst both feel like they are needed for me, they are both different things.
One being to accept GET parameters instead of just POST parameters, and the other to have an endpoint that redirects to a video.
How would prefer to do this?
My initial thought before deciding on a different endpoint was an extra json such as
"redirectToUrl": true.If it exists to redirect instead of showing the json, but it feels more right to have a different endpoint to expect a url rather than json (url only at
/api/urlinstead of/api/jsonso it's less misleading).@wukko commented on GitHub (Sep 2, 2024):
duplicate of #707, see my reply there