About one disadvantage of VK API out loud

Good day, dear residents of Habr!

I will begin with the fact that, in my understanding, Habr is a monstrous weapon in its power. Not in the sense that they can kill someone. Of course not. Simply, it gives the most ordinary developers the opportunity to share their thoughts with an amazingly wide audience. And it does not really matter what we are talking about. Whether it is your own project, carefully created in the last six months “on the knee” or the news about updates from Google and Apple, it doesn't matter. You will be heard, because here everyone is equal before karma and rating, everyone has the right to speak and vote. Democracy in all its beauty and only. But, like any weapon, Habrom must be used extremely carefully. Otherwise, the returns torment =)
')
I have long picked up a topic worthy of experiencing all the power of power transmission, and now, it seems, I found it. Let's talk about the API of the well-known social network VKontakte and what it seems to me illogical or, perhaps, slightly rudimentary, subject to revision and change? Below I will tell you how and why I came to this thought.

Attention! Those who want to discuss the latest events in the life of Pavel Durov, the FSB, or friends of schoolchildren! I ask you, for the sake of all the valuable things in your life, do not click on the “Read more” link! I would really like this post to reach its goal, and scandalousness is the last thing to do.



Social networks. The concept that entered our life is as tight as a smartphone or computer. Millions of users. Gigabytes of information. An innumerable set of application models. Social networks are especially valuable because they allow developers to knock on their users at the door: “Hey, hello! Look what a cool app! It will change your life for the better. I promise!". This is amazing! After all, we do write programs for this, exactly? To make the world better? No, of course, we like the fact that they pay a lot for our work. But it’s not the amounts on the account that warm the soul, but the numbers on the counter

When I first met the Vkontakte API, it seemed to me that the best find in my career was not yet. How many incredible ideas came to my mind from the very first lines of documentation! Of course, they do not go to any comparison in their creativity, for example, with this one . But still =) Then I did what any of you in my place would do: I began to program with enthusiasm. However, the future was not as bright as I would have liked. Behind a simple and elegant REST interface were harsh and far from always clear rules and restrictions for me.

All methods of the Vkontakte API are divided into two large classes: regular and advanced. Previously, this could be seen directly from the documentation : the descriptions of methods from different classes were in different sections, but as a result of the last update, the difference was visually smoothed out. Now those methods that used to be called advanced are simply stated in the description that they are available exclusively for standalone applications : mobile or desktop. And if you decide to write a web application that is deeply tied to VC and needs to work with, say, a wall or user messages? Here you will find disappointment.

To work with most of the VK API methods, the application will need a token. In general, the process for obtaining it looks like this:

1. The application sends the user to AUTHORIZE_URL, specifying CALLBACK_URL in the parameters;
2. Vkontakte redirects the user to the page where he confirms the access rights of the application;
3. Vkontakte redirects the user to CALLBACK_URL, in the parameters passing the token and its lifetime;
4. The application, having received a request for CALLBACK_URL, understands that it is from VC, pulls out the token and remembers it.

However, in order to get a token that provides access to advanced methods, you will have to specify https://oauth.vk.com/blank.html as a callback address. This is an API requirement. Since mobile / desktop applications, according to the authors, use the built-in browser (meaning, for example, the webkit component) to get the token, they have no problems: they capture the redirect, retrieve the user information and the token, save the whole thing and rejoice. In web applications, this obviously will not work.

I have a logical question: why? Why was this restriction introduced and why does it still exist? I can assume that the availability of calling arbitrary methods from desktops and cell phones has a simple justification: it pushes developers to create alternative clients and all kinds of instant messengers. So why not remove this ban for the web? Why put extra stick in the wheels of fantasy developers? Not all convenient and good ideas can and should be delivered as standalone, agree? In the wake of the ubiquitous "going to the clouds" and creating web applications that have tremendously broad functionality and a convenient HTML5 UI, this restriction looks like ... uncomfortable.

With the question: “Is it possible to somehow somehow get a token with the necessary privileges, if I am an honest guy and vowed not to send spam, create bots and pray to the right gods?”, I contacted Vkontakte support service. And to me, - here the drumming and the virtual plus in VK's karma, - answered, and quite quickly and politely.



Here, it seemed to me, I would go smoke and think, what hack would I have to screw in more severely, in order to get the token I needed. I would have done it, but suddenly Zen fell for me. I decided to try to change something. The problem is that the API is primarily an interface designed for third-party developers. It is used not only by me, but by thousands of other programmers who daily rivet all sorts of hacks and use dirty tricks to solve a very simple and logical task, bringing happiness and smiles to the home of the end user. It is logical to assume that these same developers should be able to somehow influence the evolution of the tool that they are invited to use. The current distinction between conventional and advanced methods creates a feeling ... well ... as if from a coffee machine, which for some reason does not know how to give change: like coffee, you can buy it, but the whole department will have to collect change.

I hope that my humble post will encourage VC to at least a dialogue with the developers, and, in the ideal case, to remove restrictions from web applications. Guys, artificial limitation is really very, very uncomfortable.

UPD. The people who think that everything is ok and that is the way it should be or puts a minus article, write in the comments - why? True interesting. This, after all, limits your freedom in working out.