Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Web apps

The Live Connect APIs enable client-side and server-side websites and scripts to work with info in Outlook.com, Microsoft OneDrive, and other services that are compatible with Live Connect. An example of a client-side or server-side website or script is a web browser or a web-browser control that enables a user to interact with a website.

Note  If you're working on a Windows Store app, a Windows Phone app, or a mobile app (even if those apps include website implementations), this isn't the topic you need. Go to Windows Store apps, Windows Phone apps, or Mobile and Windows desktop apps, respectively.

Before you can start calling the Live Connect APIs, you need a client ID, a client secret, and a redirect domain. For instructions, see Configuring your app.

Choosing an API implementation

If you're working on a client-side website or script that uses JavaScript, you use our JavaScript implementation. If you're working on a server-side website or script, or if you're working on a client-side website or script that can't use JavaScript, you use our Representational State Transfer (REST) implementation. For details, see JavaScript API (Windows 8 and web) and REST reference.

Top

Code samples

To get you started, here's the basic code that shows how to reference the Live Connect APIs, invite a user to sign in, get the signed-in user's permission to get his or her basic profile info, and display a greeting with the signed-in user's first and last names.

default.html


<!DOCTYPE html>
<html>
    <head>
        <title>Client-Side JavaScript Code Sample</title>
        <script src="constants.js"></script>
        <script src="//js.live.net/v5.0/wl.js"></script>
    </head>
    <body>
        <div id="signin"></div>
        <label id="info"></label>
        <script>
            WL.Event.subscribe("auth.login", onLogin);
            WL.init({
                client_id: APP_CLIENT_ID,
                redirect_uri: REDIRECT_URL,
                scope: "wl.signin",
                response_type: "token"
            });
            WL.ui({
                name: "signin",
                element: "signin"
            });
            function onLogin (session) {
                if (!session.error) {
                    WL.api({
                        path: "me",
                        method: "GET"
                    }).then(
                        function (response) {
                            document.getElementById("info").innerText =
                                "Hello, " + response.first_name + " " + response.last_name + "!";
                        },
                        function (responseFailed) {
                            document.getElementById("info").innerText =
                                "Error calling API: " + responseFailed.error.message;
                        }
                    );
                }
                else {
                    document.getElementById("info").innerText =
                        "Error signing in: " + session.error_description;
                }
            }
        </script>                   
    </body>
</html>


callback.html


<!DOCTYPE html>

<html>
    <head>
        <title></title>
    </head>
    <body>
        <script src="//js.live.net/v5.0/wl.js"></script>
    </body>
</html>


constants.js (replace YOUR_CLIENT_ID with your app's client ID and YOUR_REDIRECT_URL with your app's redirect URL)


var APP_CLIENT_ID = "YOUR_CLIENT_ID";
var REDIRECT_URL = "YOUR_REDIRECT_URL";

To learn what this code does, see Core concepts and Identity (profile).

To learn how to use many of the code examples throughout this documentation in the context of a larger reference code sample, see Working with the code examples.

If you're working on a server-side website or script, or if you're working on a client-side website or script that can't use JavaScript, see the REST code samples in Server-side scenarios.

Top

Testing web apps locally

When you are developing a web app, it is convenient to test the app on a local computer before you deploy it to a web server. However, the Live Connect APIs require the redirect URL to use the same domain at which the app's client ID was configured. Your local computer's web server probably uses a default address like http://localhost, so you must map your domain to the Internet Protocol (IP) address of your local web server. To do this, you add a mapping to the hosts file on your computer. (The job of the hosts file is to map host names to IP addresses.) On Windows computers, the hosts file is located at \Windows\System32\drivers\etc\hosts. On Mac OS X and most Unix computers, it is located at /private/etc/hosts. The format is the IP address, followed by the domain to map, like this.

127.0.0.1    MyDomain.com
127.0.0.1    AnotherDomain.com

The preceding example demonstrates mapping two arbitrary domain names to the IP address for localhost. With these mappings in place, every time you navigate to MyDomain.com or AnotherDomain.com, you will be redirected to 127.0.0.1 (http://localhost). The mappings in the hosts file apply to all web navigation, including redirect URLs that are returned by the Live Connect APIs. This works because the Live Connect APIs do not check the actual IP address that is in use, the APIs only verify the domain name. If your client ID was configured with a redirect URL of http://MyTestingDomain.com/MyApp/callback.htm, you update your hosts file with the following mapping: 127.0.0.1 MyTestingDomain.com. Now if you enter "MyTestingDomain.com" into your browser, it will resolve to http://localhost, so you can use your local web server for testing.

Important  

Elevated (or root) privileges are required to edit the hosts file, regardless of platform.

Tip  

You can map an externally available domain to your local server IP address, but you must comment out the mapping when you want to view the actual website. This applies only to the computer on which the hosts file was modified. This is a handy trick because it makes it easy to switch between your externally available website and your local test website.

Top

Next steps

From here, we suggest starting with the info in Core concepts, Identity API, Outlook.com API, and OneDrive API. If you're writing code for a server-side website or script, be sure to see Server-side scenarios, too.

Top

 

 

Show:
© 2014 Microsoft. All rights reserved.