SharePoint has been a cornerstone of enterprise collaboration and document management for over two decades. Behind its familiar interface lies a powerful service infrastructure that has evolved dramatically - from legacy SOAP-based services to modern RESTful APIs and Microsoft Graph integration.
This article explores how the /_vti_bin/ virtual directory, once the gateway to all SharePoint web operations, has transformed over time.
The Origins: _vti_bin and FrontPage Server Extensions
The term vti originates from Vermeer Technologies, Inc., the company behind Microsoft FrontPage - an early web authoring tool later acquired by Microsoft. Each SharePoint web application contains a virtual directory called /_vti_bin/, which serves as the endpoint for SharePoint's server-side web services.
A typical URL looks like this:
https://contoso.sharepoint.com/sites/ProjectX/_vti_bin/
Unlike physical folders, _vti_bin is virtual- managed by IIS and mapped internally to SharePoint's service architecture.
The Classic Era: SOAP Based .asmx Web Services
In the early SharePoint versions (2003-2013) developers relied on asmx (SOAP) web services for remote data access and automation. Each service was exposed through the /_vti_bin/ directory and communicated using XML over HTTP.
Service | URL Example | Description |
---|
Lists.asmx | /_vti_bin/Lists.asmx | Manage SharePoint lists — read/write items, manage attachments, etc. |
Sites.asmx | /_vti_bin/Sites.asmx | Retrieve information about site collections and subsites. |
Webs.asmx | /_vti_bin/Webs.asmx | Create or query subsites and web metadata. |
UserGroup.asmx | /_vti_bin/UserGroup.asmx | Manage site users and groups. |
Copy.asmx | /_vti_bin/Copy.asmx | Copy documents between libraries. |
SOAP based web services have major drawbacks:
The Transition- /_vti_bin/client.svc and CSOM
With SharePoint 2010, Microsoft introduced the Client-Side Object Model (CSOM), which still leveraged /_vti_bin/ but with a new service endpoint:
This provided a binary and XML-based communication model that allowed:
to communicate with SharePoint without SOAP envelopes.
The endpoint /vti_bin/client.svc/ProcessQuery handled batched queries and commands behind the scenes, forming the basis of the next generation — REST.
The Modern Era — REST API (/_api/)
From SharePoint 2013 onwards, Microsoft introduced the SharePoint REST API, offering a clean, intuitive, and modern way to interact with SharePoint data using standard HTTP verbs and JSON payloads.
Every REST API request is internally routed through the same client service:
/_api/ - /_vti_bin/client.svc/
Example — Retrieve List Items (REST)
GET https://contoso.sharepoint.com/sites/ProjectX/_api/web/lists/getbytitle('Tasks')/items
Authorization: Bearer <Access Token>
Accept: application/json;odata=nometadata
Response (JSON)
[
{
"Id": 1,
"Title": "Prepare presentation",
"Status": "In Progress"
},
{
"Id": 2,
"Title": "Submit report",
"Status": "Completed"
}
]
Simple, lightweight, and ideal for modern web and mobile applications.
SOAP vs REST- Comparison
Feature | SOAP (_vti_bin/Lists.asmx) | REST (/_api/web/lists) |
---|
Format | XML | JSON |
Endpoint | /_vti_bin/*.asmx | /_api/... |
Transport | POST with SOAPAction header | Standard HTTP verbs (GET, POST, PATCH, DELETE) |
Authentication | NTLM / Basic | OAuth 2.0 / Azure AD |
Developer Experience | Complex and verbose | Lightweight and modern |
Performance | Slower due to XML parsing | Faster, uses JSON |
Status | Deprecated | Recommended |
Microsoft Graph API
The evolution didn't stop with REST. Today, Microsoft encourages developers to use Microsoft Graph API, which unifies data access across Microsoft 365, including SharePoint, OneDrive, Teams, and Outlook.
Example:
GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items
Benefits include:
Cross-service access (OneDrive, Teams, Planner, SharePoint)
Consistent authentication via Azure AD
Rich metadata and delta query support
Long-term investment by Microsoft
Conclusion
The /_vti_bin/
directory played a foundational role in shaping SharePoint's service architecture. While the original SOAP-based services have been deprecated, their legacy paved the way for the RESTful and Graph API models that now power modern Microsoft 365 integrations.