How to add user to SharePoint group using REST & SPServices

Using REST:-

function AddUserToSPGroup()
{
var vCurrentLoggedUser2=$().SPServices.SPGetCurrentUser({fieldName: "UserName",debug: false});

vCurrentLoggedUser2= "KL\\" + vCurrentLoggedUser2;
var requestUri = _spPageContextInfo.webAbsoluteUrl + "/_api/web/sitegroups(57)/users";
$.ajax({
url: requestUri,
type: "POST",
data: JSON.stringify({'__metadata': { 'type': 'SP.User' }, 'LoginName': vCurrentLoggedUser2}),
headers:
{
"accept":"application/json;odata=verbose",
"content-type": "application/json;odata=verbose",
"X-RequestDigest":$("#__REQUESTDIGEST").val()
},
success: onSuccess,
error: onError
});//End of ajax
function onSuccess(data)
{
alert('User Added');
}
function onError(error)
{
alert(JSON.stringify(error));
}
}

Using SPServices:-

function SetContributeAccess()
{
var vCurrentLoggedUser=$().SPServices.SPGetCurrentUser({fieldName: "Title",debug: false});

$().SPServices({
   operation: "AddUserToGroup",
   groupName: "Users",
   userLoginName: vCurrentLoggedUser,
   async: false,
   completefunc: function(data,status){
      alert("User added to group");
   }// End of completefunc
}); //End  of SPServices
}//End of SetContributeAccess

SOAP vs REST. Which one to choose when?

1. REST naturally fits for Web/Cloud API's, whilst SOAP fits for distributed computing scenarios.
2.  JSON is a widely-recognized and simple standard for data exchange, and is easily read by browsers and client code, which is why most RESTful API's (Facebook and Twitter API is a good example of RESTFul API) offer JSON.
3. The RESTful Web services are completely stateless (every request is separate and not dependent on earlier request). This can be tested by restarting the server and checking if the interactions are able to survive. While, SOAP service are stateful (each request is dependent on earlier request. Hence, sometime server has to persist few request to get few info. for future  request).
4. REST is meant for caching/scalability of application. Whilst, SOAP is meant for security/contract between Client/Server.
5. REST-based implementation is simple compared to SOAP.Programming in REST is easy compare to SOAP.

Problem with SOAP (Simple Object Access Protocol):

1. Works with XML to exchange information between entities.The XML used to make requests and receive responses in SOAP can become extremely complex. In some programming languages, you need to build those requests manually, which becomes problematic because SOAP is intolerant of errors. However, other languages can use shortcuts that SOAP provides; that can help you reduce the effort required to create the request and to parse the response. In fact, when working with .NET languages, you never even see the XML. Part of the magic is the Web Services Description Language (WSDL). This is another file that’s associated with SOAP. It provides a definition of how the Web service works, so that when you create a reference to it, the IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use. In short, Many developers found SOAP cumbersome and hard to use. For example, working with SOAP in JavaScript means writing a ton of code to perform extremely simple tasks because you must create the required XML structure absolutely every time.While, REST provides a lighter weight alternative. Instead of using XML to make a request, REST relies on a simple URL in many cases.
2. Unlike SOAP, REST doesn’t have to use XML to provide the response. You can find REST-based Web services that output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can obtain the output you need in a form that’s easy to parse within the language you need for your application.

Deciding Between SOAP and REST

SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:

• Language, platform, and transport independent (HTTP / SMTP / FTP) (While, REST requires use of HTTP)
• Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
• Standardized
• Provides significant pre-build extensibility in the form of the WS* standards
• Built-in error handling
• Automation when used with certain language (like .Net) products.
• Mainly meant for enterprise application (bank website, organisation website etc.) since SOAP provide advantage of security feature (WS-Transaction specification).

REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:

• No expensive tools require to interact with the Web service
• Smaller learning curve
• Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
• Fast (no extensive processing required)
• Closer to other Web technologies in design philosophy
• Support more interoperability compare to SOAP. Check here.
• Mainly used for Internet facing application (Facebook, Twitter) since REST brings advantage of scalabilty and speed.Check here (After all that information, aren't you telling me that REST is good for Internet-facing applications, and SOAP for enterprise applications?)

Reference document (best article to understand SOAP and REST in few min.) Thanks to John Mueller.

http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/

What is REST?

Official Definition of REST
REST is an architecture style (concepts / theory) built on certain principle of web. REST is a PROTOCOL design on HTTP. REST is an architecture for how to send messages back and forth from a client to server using HTTP.

Define Protocol: 
Set of rules for requesting information from server using special technique.

Representational state transfer is using WEB feature in simple and effective way. It take advantage of 40 years old matured HTTP protocol features/methods and apply its own PRINCIPLES. 

HTTP features like 

• GET/PUT/POST/Delete methods on resources, 
• http protocol is stateless.
• URI - locate anything on web.

REST Principles:

1. RESOURCES - Everything is RESOURCE from REST point of view e.g. images / files / videos etc. So think everything as RESOURCE.
2. IDENTIFIER - REST always GET the resource by UNIQUE identifies. e.g. http://www.google.com/Customers/Chintan OR http://www.google.com/Customers/items(111)
3. INTERFACE - Keep your interface simple and uniform to achieve CRUD operations like it uses HTTP METHODS GET / PUT / DELETE / POST to do the operations rather than allowing user to create their own methods and spread confusion. Hence, REST will use HTTP methods to work with resource to maintain uniformity.
4. REPRESENTATION - All communication happen between client and server and vice-versa is called as  REPRESENTATION. The server might respond it in XML or JSON format depending on what developer has specify on their application.
5. STATELESS - Every request is stateless. Every request which you send is independent of earlier request. Server need not have to remember the state of every request. e.g. if client try to access server for the first time, server ask for authentication. Once successfully authenticated, if client make 2nd request, then server along with request, client also send SUCCESS authentication message so server need not ask for authentication.

Why REST?
It take advantage of HTTP and allow to boost application performance and scalibility.