Whoever worked with SharePoint APIs at least once probably might have seen the _vti_bin path in some of its URIs. Not sure about you, but I have always wondered why Microsoft would have chosen that particular name as an identifier and a while ago I decided unveil the “secret” behind it.
First things first, I’ll tell you how I ended up investigating all those things. As I said, a while ago I had a requirement in a project that I was working on to copy some pages with all its webparts.
At that time PnP didn’t exist, so there were no provision techniques to handle such requirement.
I tried a lot of ways of exporting the desired file and then importing it again, but none of them really worked. All webparts were removed after reimporting the file – that behaviour was related with the ghosted files, but that is a subject to another post.
SharePoint Designer to the rescue
After trying a lot of different methods without success, I was starting to wonder whether would be possible to tackle that requirement or not and, for my complete astonishment, when I copied the page using the SharePoint Designer, all webparts were copied as well.
So, if SharePoint Designer was capable of doing such a thing, so was I. I started fiddler, did the very same process again, and started to evaluate the request that was just executed.
The following immediately got my attention:
HTTP POST /_vti_bin/_vti_aut/author.dll
Headers: X-Vermeer-Content-Type = application/x-www-form-urlencoded
At that time, to tackle that requirement I had created a PowerShell script that would do the same request and thus fulfilling the goal. If you are interested in the script, please check it out in the following Github repository: https://github.com/RARomano/CopyPageWithWebParts/blob/master/clonePageWithWebparts.ps1
Apart from that, there are a lot of other endpoints that are (or were) often used by SharePoint developers, like /_vtin_bin/listdata.svc.
The origin of the _vti_bin
Now that the story has been told and at that time, my issue was fixed, it was about time to find out more about the _vti_bin.
Tracing back to very beginning, you’d find the following article https://news.microsoft.com/1996/01/16/microsoft-acquires-vermeer-technologies-inc/ that dates back to 1996!
At that time, Microsoft has acquired a company called Vermeer Technologies Inc. (Does that ring a bell? If not, just look at the request header that was sent by SharePoint Designer: X-Vermeer-Content-Type)
With that acquisition, Microsoft had also incorporated a Vermeer’s flagship software: FrontPage.
Long story short, Vermeer’s developers decided to call the FrontPage extensions folder as VTI, that stands for Vermeer Technologies Inc. So, when those FrontPage Extensions were ultimately included in SharePoint, the folder name remained the same. Pretty cool, isn’t it?
So, if you’d like to know more about other APIs available in SharePoint through FrontPage Extensions, click here.