Traditional server-side controls approach to building a web-based user experience include master pages, application pages, themes, cascading style sheets (CSS), Web Parts, delegate controls, navigation controls and providers, and so on. SharePoint uses these resources to construct an ASP.NET page dynamically. This is then converted into HTML, packaged into an HTTP response, and sent to the web browser on the client. Here All the logic execute on the server and proceeds with a full page postback.
Info flow is Browser -Get/Put/Post---> ASP.net page (with web controls) --> SharePoint Object Model --> ASP.net page -HTML--> Browser.
This approach has the disadvantages like limited interactivity, high response time etc. Rich Internet Application technologies like Ajax, Silverlight, Flash provide more engaging user experience since it execute some logic on browser rather than relying entirely on server side execution. RIA tech use async communication without reloading entire page - it disassembles request from response and results more responsive work and ability to perform work in parallel.
AJAX (Async JavaScript and XML) is a set of technologies that allow us to retrieve data asynchronously from the server and manipulate data in client computer without disrupting entire page. AJAX traditionally rely on Javascript XMLHttpRequest API to send async requests to web server and to return the response to the calling script, the script could then use the response to retrieve and manipulate the DOM of current page (value of a table cell etc). Popular Javascript frameworks such as JQuery (jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. AJAX is a technique to do an XMLHttpRequest (out of band Http request) from a web page to the server and send/retrieve data to be used on the web page. AJAX stands for Asynchronous Javascript And XML. It uses javascript to construct an XMLHttpRequest, typically using different techniques on various browsers. jQuery is a javascript framework that makes working with the DOM easier by building lots of high level functionality that can be used to search and interact with the DOM. Part of the functionality of jQuery implements a high-level interface to do AJAX requests. jQuery implements this interface abstractly, shielding the developer from the complexity of multi-browser support in making the request. In nutshell Ajax is a technology / paradigm, whereas jquery is a library (which provides - besides other nice functionality - a convenient wrapper around ajax).AJAX is a way of sending information between browser and server without refreshing page. It can be done with or without library like jQuery. AJAX is the underlying technology for every website that doesn't do a refresh to perform some server-side functionailty. AJAX is provided by javascript using the XMLHttpRequest object which is the heart of AJAX. jQuery, Prototype, Dojo, and all other client side frameworks, are just providing a wrapper for the XMLHttpRequest object so that it makes it browser compatible and easy to use. This is because using the XMLHttpRequest object natively can be quite difficult and may not work across all browsers the way you intend.
Silverlight is a development platform that enables you to create rich, engaging applications that run in web browsers and on other devices. Silverlight developers use a specialized, lightweight version of the Microsoft .NET Framework to create applications. Alongside the benefits of a familiar .NET development experience, Silverlight offers capabilities in areas such as graphics, animation, and multimedia that go well beyond what you can achieve with Ajax.It's increasingly common to use a combination of Silverlight applications, Ajax elements, and traditional server-side controls together to provide a full range of functionality for SharePoint users. Silverlight applications can also interact directly with Ajax elements on a page.
Client Side application is any logic that interacts with SP data from an external computer including browser, stand alone solutions and mobile devices. Client Side logic development will provide the advantages like richer UX, option to modify data from other app like custom solution. Usually compiled Silverlight applications (XAP files) are hosted within HTML object elements, which can either be embedded in the page or generated dynamically through JavaScript. In the case of a SharePoint web page, Silverlight applications are typically hosted within a Web Part. SharePoint 2010 includes a Silverlight Web Part that is specifically designed for hosting XAPs within a SharePoint page. Just like web pages that contain Ajax-enabled components, the browser must use a traditional synchronous page load at least once in order to render the page and download associated resources, such as the Silverlight XAP and any JavaScript files. Silverlight applications can also interact directly with Ajax elements on a page.
Client Object model provide a subset of classes in server side (microsoft.sharepoint.dll) assembly and are implemented as a WCF service (/_vti_bin/client.svc) , but they use web bindings to implement efficient request batching(Bindings are used to specify the transport, encoding, and protocol details required for clients and services to communicate with each other. WCF uses bindings to generate the underlying wire representation of the endpoint, so most of the binding details must be agreed upon by the parties that are communicating.). Commands are serialized into XML and sent to the server in a single HTTP request. For every command, a corresponding server object model call is made, and the server returns a response to the client in compacted JavaScript Object Notation (JSON) format, which the proxy parses. The client APIs provide a familiar, object-oriented interface to the WCF service, so developers are shielded from the details of the service. In particular, the client-side runtime handles all communication between the clients and server.
Three Client object model Sp2010
There are 3 approaches to access SharePoint data from client apps.
For future compatability, its advisable to use CSOM and REST.
Of the three principal approaches to client-side data access, using the CSOM APIs is the only approach that provides the kind of hierarchical, strongly-typed representation of SharePoint objects, such as sites and Webs, that compares to server-side development. The CSOM is the only approach for any client-side data access scenarios beyond list queries. The CSOM allows you to query SharePoint lists by creating CAML queries. This is the most efficient way to query lists, although it requires that developers revert to creating CAML queries. Specific cases where you should favor the use of the CSOM include the following:
You need to perform advanced list operations, such as complicated joins or paging. You can also perform joins through REST requests, although this is subject to various limitations.
You need to manipulate SharePoint objects, such as sites or Webs.
You need client-side access to other areas of SharePoint functionality, such as security. Although the CSOM APIs mirror the server APIs in terms of functionality, the way CSOM actually works necessitates some changes to the way in which you approach your development tasks. The CSOM uses a set of specialized Windows Communication Foundation (WCF) services to communicate with the SharePoint server. Each API is optimized to work efficiently with remote clients and with the asynchronous loading model used by the Ajax and Silverlight frameworks.
Note: All the CSOM APIs include a ClientContext class that manages the interaction between client-side application code and the SharePoint server. Before you perform any operations in client-side code, you must instantiate a ClientContext object with the URL of a SharePoint site
The client-side code uses the ClientContext class to define a series of operations to execute against a SharePoint site. In this example, the operations are the following:
Retrieve the Parts list.
Retrieve the Inventory Locations list.
Build a query for the Parts list.
Build a query for the Inventory Locations list.
Execute the query against the Parts list.
Execute the query against the Inventory Locations list.
Load the Parts query results (which causes them to be returned to the client).
Load the Inventory Locations query results.
The client code calls the ClientContext.ExecuteQueryAsync method. This instructs the CSOM to send a request containing all operations to the server.
The SharePoint server executes the series of operations in order and returns the results to the client. The CSOM notifies the client-side code of the results by invoking the callback method associated with the onQuerySucceed delegate. This request batching process helps to improve performance and reduce network traffic in two ways. First, fewer Web service calls occur between the client and the SharePoint server, which reduces the "chattiness" of the client-server interface. For example, you can perform two list queries in a single request. Second, as a set of operations occur on the server in a single request, the data being acted on doesn't need to be moved between the client and the server for the intermediate operations—only the list of operations and the final result set are passed between the client and the server.
Request batching requires a different mindset when you create queries from client-side code. First, be aware that you do not have access to any results until you call ExecuteQueryAsync (or ExecuteQuery) and receive the call back with the results. If you need to implement conditional logic in the client-side code that can't be expressed in the command list that you send to the server, you will need to execute multiple queries. Second, you should aim to group your operations to minimize the number of service calls. This means you may need to think about how you sequence your logic in order to take full advantage of request batching.
Representational State Transfer (REST) interface is a WCF data service that allows us to use construct HTTP request to query SharePoint list data. Like all RESTful Web services, the SharePoint REST interface maps HTTP verbs to data operations, as
GET - Retrieve
POST - Create
PUT - Update (update all fields and use default values for any undefined fields)
DELETE - Delete
MERGE - Update (update only the fields that are specified and changed from current version)
In practice, many firewalls and other network intermediaries block HTTP verbs other than GET and POST. To work around this issue, WCF Data Services (and the OData standard) support a technique known as "verb tunneling." In this technique, PUT, DELETE, and MERGE requests are submitted as a POST request, and an X-HTTP-Method header specifies the actual verb that the recipient should apply to the request.
The SharePoint REST interface is based on the REST-based Open Data protocol (OData) for Web-based data services, which extends the Atom and AtomPub syndication formats to exchange XML data over HTTP. Because OData is a platform-independent open standard, the SharePoint REST interface is a great way to access SharePoint list data from platforms on which the CSOM may be unavailable to you, such as from non-Windows–based operating systems. However, the REST interface only provides access to list data—if you need to manipulate other data on your SharePoint site, you will need to use the CSOM. The REST implementation can also return the output in JavaScript Object Notation (JSON) format as an alternative to an ATOM feed. JSON is a compact representation of the returned results that can be easily parsed by JavaScript clients.
Ref:
Info flow is Browser -Get/Put/Post---> ASP.net page (with web controls) --> SharePoint Object Model --> ASP.net page -HTML--> Browser.
This approach has the disadvantages like limited interactivity, high response time etc. Rich Internet Application technologies like Ajax, Silverlight, Flash provide more engaging user experience since it execute some logic on browser rather than relying entirely on server side execution. RIA tech use async communication without reloading entire page - it disassembles request from response and results more responsive work and ability to perform work in parallel.
AJAX (Async JavaScript and XML) is a set of technologies that allow us to retrieve data asynchronously from the server and manipulate data in client computer without disrupting entire page. AJAX traditionally rely on Javascript XMLHttpRequest API to send async requests to web server and to return the response to the calling script, the script could then use the response to retrieve and manipulate the DOM of current page (value of a table cell etc). Popular Javascript frameworks such as JQuery (jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. AJAX is a technique to do an XMLHttpRequest (out of band Http request) from a web page to the server and send/retrieve data to be used on the web page. AJAX stands for Asynchronous Javascript And XML. It uses javascript to construct an XMLHttpRequest, typically using different techniques on various browsers. jQuery is a javascript framework that makes working with the DOM easier by building lots of high level functionality that can be used to search and interact with the DOM. Part of the functionality of jQuery implements a high-level interface to do AJAX requests. jQuery implements this interface abstractly, shielding the developer from the complexity of multi-browser support in making the request. In nutshell Ajax is a technology / paradigm, whereas jquery is a library (which provides - besides other nice functionality - a convenient wrapper around ajax).AJAX is a way of sending information between browser and server without refreshing page. It can be done with or without library like jQuery. AJAX is the underlying technology for every website that doesn't do a refresh to perform some server-side functionailty. AJAX is provided by javascript using the XMLHttpRequest object which is the heart of AJAX. jQuery, Prototype, Dojo, and all other client side frameworks, are just providing a wrapper for the XMLHttpRequest object so that it makes it browser compatible and easy to use. This is because using the XMLHttpRequest object natively can be quite difficult and may not work across all browsers the way you intend.
Silverlight is a development platform that enables you to create rich, engaging applications that run in web browsers and on other devices. Silverlight developers use a specialized, lightweight version of the Microsoft .NET Framework to create applications. Alongside the benefits of a familiar .NET development experience, Silverlight offers capabilities in areas such as graphics, animation, and multimedia that go well beyond what you can achieve with Ajax.It's increasingly common to use a combination of Silverlight applications, Ajax elements, and traditional server-side controls together to provide a full range of functionality for SharePoint users. Silverlight applications can also interact directly with Ajax elements on a page.
Client Side application is any logic that interacts with SP data from an external computer including browser, stand alone solutions and mobile devices. Client Side logic development will provide the advantages like richer UX, option to modify data from other app like custom solution. Usually compiled Silverlight applications (XAP files) are hosted within HTML object elements, which can either be embedded in the page or generated dynamically through JavaScript. In the case of a SharePoint web page, Silverlight applications are typically hosted within a Web Part. SharePoint 2010 includes a Silverlight Web Part that is specifically designed for hosting XAPs within a SharePoint page. Just like web pages that contain Ajax-enabled components, the browser must use a traditional synchronous page load at least once in order to render the page and download associated resources, such as the Silverlight XAP and any JavaScript files. Silverlight applications can also interact directly with Ajax elements on a page.
Client Object model provide a subset of classes in server side (microsoft.sharepoint.dll) assembly and are implemented as a WCF service (/_vti_bin/client.svc) , but they use web bindings to implement efficient request batching(Bindings are used to specify the transport, encoding, and protocol details required for clients and services to communicate with each other. WCF uses bindings to generate the underlying wire representation of the endpoint, so most of the binding details must be agreed upon by the parties that are communicating.). Commands are serialized into XML and sent to the server in a single HTTP request. For every command, a corresponding server object model call is made, and the server returns a response to the client in compacted JavaScript Object Notation (JSON) format, which the proxy parses. The client APIs provide a familiar, object-oriented interface to the WCF service, so developers are shielded from the details of the service. In particular, the client-side runtime handles all communication between the clients and server.
Three Client object model Sp2010
- Client Object Model for Silverlight apps : object model will either be downloaded as part of the .xap file or the file Microsoft.SharePoint.Client.xap seperate.
- Client Object Model for .Net : called only if the object model assembles installed in client computer (silvelight redistribution package) Info Flow is ... Managed Control & Logic (Managed Client) --> Managed COM --> Proxy -XML request-> Client.svc (SharePoint server) --> Server Object Model --> Content DB --> Server Object Model --> Client.svc -JSON Response-> Managed COM --> Managed Control & Logic (Managed Client)
- Client Object Model for JavaScript : the constituent .js files downloaded automatically into users computer when a page references the object model is accessed. Info Flow is ... Javascript Control & Logic (Browser) --> Javascrict COM --> Proxy -XML request-> Client.svc (SharePoint server) --> Server Object Model --> Content DB --> Server Object Model --> Client.svc -JSON Response-> Javascript COM --> Javascript Control & Logic (Browser)
There are 3 approaches to access SharePoint data from client apps.
- Client side object model : 3 seperate APIs that provide a subset of Server Object Model for client side usage. ECMA Script client object model, Silverlight client Object Model and .Net managed client object model
- REST (Representational State Transfer) Interface uses WCF Data Services to expose SP Lists and ListItems as addressable resources that can be accessed through HTTP requests. REST interface maps read, create, update and delete operations to GET, POST, PUT and DELETE HTTP verbs.
- ASP.Net web services are nothing but the ASMX web services that were available in prior sharepoint version
For future compatability, its advisable to use CSOM and REST.
Of the three principal approaches to client-side data access, using the CSOM APIs is the only approach that provides the kind of hierarchical, strongly-typed representation of SharePoint objects, such as sites and Webs, that compares to server-side development. The CSOM is the only approach for any client-side data access scenarios beyond list queries. The CSOM allows you to query SharePoint lists by creating CAML queries. This is the most efficient way to query lists, although it requires that developers revert to creating CAML queries. Specific cases where you should favor the use of the CSOM include the following:
You need to perform advanced list operations, such as complicated joins or paging. You can also perform joins through REST requests, although this is subject to various limitations.
You need to manipulate SharePoint objects, such as sites or Webs.
You need client-side access to other areas of SharePoint functionality, such as security. Although the CSOM APIs mirror the server APIs in terms of functionality, the way CSOM actually works necessitates some changes to the way in which you approach your development tasks. The CSOM uses a set of specialized Windows Communication Foundation (WCF) services to communicate with the SharePoint server. Each API is optimized to work efficiently with remote clients and with the asynchronous loading model used by the Ajax and Silverlight frameworks.
Note: All the CSOM APIs include a ClientContext class that manages the interaction between client-side application code and the SharePoint server. Before you perform any operations in client-side code, you must instantiate a ClientContext object with the URL of a SharePoint site
The client-side code uses the ClientContext class to define a series of operations to execute against a SharePoint site. In this example, the operations are the following:
Retrieve the Parts list.
Retrieve the Inventory Locations list.
Build a query for the Parts list.
Build a query for the Inventory Locations list.
Execute the query against the Parts list.
Execute the query against the Inventory Locations list.
Load the Parts query results (which causes them to be returned to the client).
Load the Inventory Locations query results.
The client code calls the ClientContext.ExecuteQueryAsync method. This instructs the CSOM to send a request containing all operations to the server.
The SharePoint server executes the series of operations in order and returns the results to the client. The CSOM notifies the client-side code of the results by invoking the callback method associated with the onQuerySucceed delegate. This request batching process helps to improve performance and reduce network traffic in two ways. First, fewer Web service calls occur between the client and the SharePoint server, which reduces the "chattiness" of the client-server interface. For example, you can perform two list queries in a single request. Second, as a set of operations occur on the server in a single request, the data being acted on doesn't need to be moved between the client and the server for the intermediate operations—only the list of operations and the final result set are passed between the client and the server.
Request batching requires a different mindset when you create queries from client-side code. First, be aware that you do not have access to any results until you call ExecuteQueryAsync (or ExecuteQuery) and receive the call back with the results. If you need to implement conditional logic in the client-side code that can't be expressed in the command list that you send to the server, you will need to execute multiple queries. Second, you should aim to group your operations to minimize the number of service calls. This means you may need to think about how you sequence your logic in order to take full advantage of request batching.
Representational State Transfer (REST) interface is a WCF data service that allows us to use construct HTTP request to query SharePoint list data. Like all RESTful Web services, the SharePoint REST interface maps HTTP verbs to data operations, as
GET - Retrieve
POST - Create
PUT - Update (update all fields and use default values for any undefined fields)
DELETE - Delete
MERGE - Update (update only the fields that are specified and changed from current version)
In practice, many firewalls and other network intermediaries block HTTP verbs other than GET and POST. To work around this issue, WCF Data Services (and the OData standard) support a technique known as "verb tunneling." In this technique, PUT, DELETE, and MERGE requests are submitted as a POST request, and an X-HTTP-Method header specifies the actual verb that the recipient should apply to the request.
The SharePoint REST interface is based on the REST-based Open Data protocol (OData) for Web-based data services, which extends the Atom and AtomPub syndication formats to exchange XML data over HTTP. Because OData is a platform-independent open standard, the SharePoint REST interface is a great way to access SharePoint list data from platforms on which the CSOM may be unavailable to you, such as from non-Windows–based operating systems. However, the REST interface only provides access to list data—if you need to manipulate other data on your SharePoint site, you will need to use the CSOM. The REST implementation can also return the output in JavaScript Object Notation (JSON) format as an alternative to an ATOM feed. JSON is a compact representation of the returned results that can be easily parsed by JavaScript clients.
Ref:
- http://msdn.microsoft.com/en-us/library/ee537247.aspx
- http://msdn.microsoft.com/en-us/library/ff798413.aspx
- http://msdn.microsoft.com/en-us/library/ff521587(v=office.14).aspx
- http://msdn.microsoft.com/en-us/library/ff798339.aspx
- http://msdn.microsoft.com/en-us/library/ff521587(office.14).aspx
- http://msdn.microsoft.com/en-us/library/ee535480(v=office.14).aspx
- http://msdn.microsoft.com/en-us/data/ff478141.aspx
