One of the most interesting things about Microsoft SharePoint is its vast flexibility. Unfortunately, that flexibility requires developers to think about structure before things get crazily unwieldy. Adding to the confusion are terms that Microsoft hasn't kept completely consistent. In order to clarify things for my team, I spent some time working through some of the differences and trying to create some sensible definitions.
A main source of confusion is that the SharePoint user interface (UI) uses one set of terms, but the SharePoint application programming interface (API) often uses a different set of terms. Below is a chart of the main terms with differing names:
|SharePoint UI Term||SharePoint API Class|
|Top Level Site||Microsoft.SharePoint.Client.RootWeb|
So a Site is really a Web! Below is a more detailed SharePoint dictionary:
- Farm (on-premises)
- A logical grouping of multiple SharePoint on-premises servers (a.k.a. Web Applications) that share common resources managed via a central configuration database.
- Web Application (on-premises)
- Typically, the front-end domain through which a user interacts with SharePoint. Associated with one or more SharePoint content databases. A single application pool under IIS and can be restarted independently. Can have multiple Site Collections. Roughly equivalent to a SharePoint Online Tenant (Microsoft.Online.SharePoint.TenantAdministration.Tenant).
- Site Collection (The API doesn’t define a SiteCollection class)
- (a.k.a. Site) Microsoft.SharePoint.Client.Site. Within a single on-premises Web Application or within a single Online tenancy, a single top-level site (a.k.a. RootWeb (Microsoft.SharePoint.Client.Web)) and its collection of sub-Webs. Defines functionality, navigation, and administration to be inherited by the RootWeb’s sub-Webs.
- Microsoft.SharePoint.Client.Web. One of a Site’s Webs collection (Microsoft.SharePoint.Client.WebCollection), that initially inherits properties from the Site’s RootWeb, but can have unique permissions set for its objects. Can have sub-Webs (Microsoft.SharePoint.Client.WebCollection).
- Microsoft.SharePoint.Client.Web. A special type of Web (a.k.a. the Top-Level Site) that defines, among other things, the permissions that will be inherited by any child Webs.
- Microsoft.SharePoint.Client.List. A primary building block for SharePoint--almost everything in SharePoint is stored in a list of some kind. A list has one or more columns, a.k.a. fields (Microsoft.SharePoint.Client.FieldCollection), properties, or metadata. A list is associated with one or more content types (Microsoft.SharePoint.Client.ContentTypeCollection). A list is a container for information, roughly similar to a very simple database or spreadsheet. Data is gathered in rows, and each row is known as a list item. Lists where each item contains a file (and, in the other columns/fields, data about that file) are called libraries in SharePoint. A Document Library is a special kind of SharePoint list. Security on a list is governed by Role Assignments (Microsoft.SharePoint.Client.RoleAssignment), which are linked to Role Definitions (Microsoft.SharePoint.Client.RoleDefinition) and specific Permissions (Microsoft.SharePoint.Client.PermissionKind).
- Microsoft.SharePoint.Client.Field. Contains the definition of a site or list column. A column represents an attribute, or piece of metadata, that the user wants to manage for the items a List or Content Type. Site Columns are defined at the Site level, then applied to lists or Content Types in child Webs.
- Content Types
A group of reusable settings that describe the shared behaviors for a specific type of content. Each Content Type can specify:
- The document template on which to base new items of this type
- Custom forms (New, Edit, Display) to use with this Content Type
- Workflows available for items of this Content Type
- Custom solutions or features associated with this Content Type
List Content Types are associated with a List or Library. List Content Types are children of the Site Content Types from which they are created.
- Microsoft.SharePoint.Client.Principal. A User or Group that needs permission. Permissions are assigned to Principals.
- Securable Objects
- Microsoft.SharePoint.Client.SecurableObject. Objects that users can access if they have permission, such as Sites, Webs, Lists, Libraries, Folders, Documents, or Items. Role Assignments are linked to the SecurableObject, inherited from the parent object. Everything in a Site (a.k.a. Site Collection) inherits permissions from the RootWeb. This inheritance can be broken and permissions assigned to the individual objects.
- Microsoft.SharePoint.Client.BasePermission. The level of access a user has to a securable object. SharePoint 2013 comes with 33 built-in Permissions. Permissions are too fine-grained to be applied in a practical way to an individual user. Instead they are applied to Role Definitions and permission policies.
- Microsoft.SharePoint.Client.Group. Defined at the Site level, a collection of SharePoint Users.
- Microsoft.SharePoint.Client.User. Defined at the Site level, a single SharePoint account from any authentication provider supported by the Web Application. Can be associated with Groups or assigned directly to a Site, sub Web, List or Library.
- Role Definition
- Microsoft.SharePoint.Client.RoleDefinition. Defines a single role definition, includeing a name, description, and a set of rights or Permissions (Microsoft.SharePoint.Client.BasePermissions). The role definitions Limited Access and Full Control cannot be changed.
- Role Assignment
- Microsoft.SharePoint.Client.RoleAssignment. For any Securable Object, links Principals and Role Definitions via RoleDefinitionBindings. This defines the role assignments for a user or group on the Web site, list, or list item. Members (which can be Users or Groups) is the list of entities associated with the role assignment.
- Microsoft.SharePoint.Client.PermissionKind. Specifies permissions that are used to define user roles.
Hope this helps!