Make API more straight forward

[singhpratyush]

The Problem

As of now, we use complex URLs to refer to videos, which can only be generated on the server. This means that if someone wishes to download a song from our API, she will have to search for it using our API. This means that she will be making some request to our server and our server will be wasting precious time processing it.

Looking at the overview, we are sacrificing our computing resource just to introduce redundancy.

Moreover, we need to specify many parameters to generate the encodes string. In this way, we can't serve requests for whom we only know the video ID (we need more things to encode). This impacts the scale of application (as I had noticed while working on lite-explode part).

New API

The new API I am thinking of will be simple -

• /api/v3/search?q=numb
  Additional tools that will be available to clients so that they may get music flavored results (if they can't do it themselves).
• /api/v3/video/get?id=kXYiU_JCYtU&offset=120
  Serve with offset of 2 sec, can work for both stream and download. Length restriction will take place here.
• /api/v3/video/info?id=kXYiU_JCYtU&basic=1&suggestions=1
  Additional tool to show basic info of video and also the related videos.
• /api/v3/playlist/info?id=PLlqZM4covn1Ht1ANj5N8AX2viCKStDWl8
  An additional tool to show details of the playlist. Length will be restricted.
• ...

In this way, we can simply get AnyAudio for a Youtube video if we just know its ID.

Overview

So this is what will be happening -

• You need to get the audio-only format of some video? Fine, give us the video ID.
• Don't have ID? Fine, give us a query so that we may show you some results that may be of your interest.
• Ok, here is the direct download link. No bullshit.
• Interested in more videos like that, we'll help if you can't find some on your own.

This would lower effort of the server but would work only if the clients are smart. That is, they need to perform the search for themselves, get to know about a video/playlist, etc. all by themselves.

Threats

With the current API, it's hard to guess API usage if you are new to this world (but its doable). Whereas in the new case, things will be quite simple. So we may encounter times when someone/something start making lots of requests to our server to get songs.

But if we look carefully, the situation is not avoidable even with the current structure.

@ansarimofid @aviaryan @bxute: What are your views?

[aviaryan]

@singhpratyush In general, this proposal looks good. I haven't reviewed it deeply though. I want to say that we should first concentrate on issues that are smaller/more important/less breaking/more concerned with user. This is because we need to do a public release as soon as possible. So let's do this after the release. We can work on #112 (feature to contact the developers) , #115 (adverts in website) instead in the meanwhile.

[michelkaeser]

+1