SUMS – Social and everything else

LinkedIn allows developers to extend their site or application by using the LinkedIn REST API. The integration itself is very straightforward. You just need an API Key, and some basic principles of the REST API [1]. In addition to that, the JavaScript API acts as a bridge between the user and the REST API, and gives you a way to interact with the the REST API without actually making calls — they requests are automatically translated into a REST call via Ajax.

REST API

Below you find the resources available for the LinkedIn API, as well as some basic description for each one of them.

• Profile
• Connections
• Search
• Messaging
• Network Updates

In this architecture, every resource is access via an HTTP GET request. The Profile resource provides all the information that is available for a user, based on selectors (user id or profile url). In order to get further information about a user’s network (connections, activity, etc.), Connections resource provides you with details regarding user’s connection. Searching through the LinkedIn network is achieved using the Search resource, which matches the criteria provided. Messaging resource allows users to send and receive private messages, as well as invitations to connect. Please note that, Messaging requires HTTP POST requests rather than GET. To post updates, receive updates, get comments and/or likes, you have to use the Network resource. Every HTTP request (either POST or GET), returns an XML with the appropriate data requested.

Request Examples

Search for people with keywords anargyros akrivos:

HTTP GET http://api.linkedin.com/v1/people-search?keywords=[anargyros akrivos]

Get profile information for user akrivos:

HTTP GET http://api.linkedin.com/v1/people/id=akrivos

Get akrivos‘ connections:

HTTP GET http://api.linkedin.com/v1/people/id=akrivos/connections

Getting updates for Vanessa Hughes

HTTP GET http://api.linkedin.com/v1/people/id=QpK8ApA59n/network/updates?scope=self

Response Example

<updates total="250" start="0" count="10">
  <update>
    <timestamp>1265688025372</timestamp>
    <update-key>STAT-11737890-270-*1</update-key>
    <update-type>STAT</update-type>
    <update-content>
      <person>
        <id>QpK8ApA59n</id>
        <first-name>Vanessa</first-name>
        <last-name>Hughes</last-name>
        <headline>Certified eBay Trading Asst & Power/TOP Seller of ANTIQUE WESTERN ITEMS</headline>
        <current-status>I new I had a good plan & then I get this...Seller Special: 50% OFF SALE2 days only! Feb 9-10 #Ebay</current-status>
        <picture-url>http://media.linkedin.com/mpr/mprx/0__by8vxfjBizcc5a135g1vpgtv6tBz_a13Le0vjpGEiQboFJPfTuuRge2Ue-enkf0CkYYssC1AxTS</picture-url>
        <api-standard-profile-request>
          <url>http://api.linkedin.com/v1/people/QpK8ApA59n:full</url>
          <headers total="1">
            <http-header>
              <name>x-li-auth-token</name>
              <value>name:D6nh</value>
            </http-header>
          </headers>
        </api-standard-profile-request>
        <site-standard-profile-request>
          <url>http://www.linkedin.com/profile?viewProfile=&key=11737890&authToken=D6nh&authType=name&trk=api*a102812*s1397*</url>
        </site-standard-profile-request>
      </person>
    </update-content>
    <is-commentable>true</is-commentable>
  </update>
  ...
</updates>

JavaScript API

Using JavaScript API [2] unleashes the full power of LinkedIn REST API. Assuming that you have the API Key, you just need to include a JavaScript provided by LinkedIn as follows:

<script type="text/javascript" src="http://platform.linkedin.com/in.js">
    api_key: YOUR-API-KEY
    onLoad: onLinkedInLoad
    authorize: true
</script>

The IN object is the basic JavaScript object for accessing the JavaScript API. Every function call begins with IN.

Issues to bear in mind

The basic issue is that many LinkedIn API calls require that the user is authenticated, making user authorisation a necessary evil, before making any call to the API.

References

[1] http://developer.linkedin.com/docs/DOC-1258
[2] http://developer.linkedin.com/docs/DOC-1206

This week we have defined the software architecture for our web application. Everything is organised into modules (layers), so that the application is scalable and flexible. Even though the number of layers increases the total number of lines of code, it assures that every additional module can be integrated with a minimum of effort.

We have identified 5 major layers:

1. UI (view) – this is represented by the application’s web pages on which the users provide input and get their results back
2. controller – this is the application’s core and it manages everything: from database persistence to information retrieval from the supported social networks
3. facade – this layer unifies all the social networks so that the controller communicates with only one module to retrieve information
4. the social networks layer – represented by individual modules for each supported social network
5. the model – which is represented by a database with a persistency package on top (an ORM tool who’s entities can be wrapped into DTOs, for easier manipulation)

Although the searches through our web application can be done in real time, it is useful to implement a caching mechanism which stores the information into the database so that the users can see the evolution of a certain search query over time. This would also improve response time for the queries on which the user would like to see a time evolution, since the results are already stored and not fetched during the search.

Social Aggregator Software Architecture

After giving a first description of our system summarising its requirements, we aim now to provide a more formal narrative description of them. The formal description separates the requirements in functional and non-functional according to their nature.

Functional Requirements

The table below lists the functional requirements of our system, indicating the core, extended and advanced features of our system. Every requirement is assigned a unique id that can be used to identify it. The functionality level indicates the stage of the development that the requirements shall be addressed.

Non-Functional Requirements

The table below defines the non-functional requirements of the system, paying special attention to usability and performance issues. Every requirement is assigned a unique id that can be used to identify it. The functionality level indicates the stage of the development that the requirements shall be addressed.

After specifying the requirements of the system in detail, it was vital to map those using UML and Block diagrams, and achieve a more formal description of the system. The diagrams are high level and are used to help our readers to understand what our system will be about. Lower level diagrams may be needed to facilitate the interaction between the members of the team. However, this is going to be decided after the initiation of the development process.

High Level Architecture

Below there is a High Level Architecture diagram of the Systems. It maps the way that the aggregator will interact with the external systems (Social Networks) and the Users.

High Level Architecture of the Aggregator

Use Case Diagram

Below there is a Use Case Diagram. The black use cases show the core functionality of the system, while the red use cases map the “Extended” and “Advanced” features, as they were described in our previous post. The previous post documents the use case diagram.

Use Case Diagram

Sequence Diagrams

Two Sequence Diagrams, which describe different scenarios of the system, follow as well as documentation for each of them. The scenarios are representative and can be also used for demos, should the features of the system are to be demonstrated.

Sequence Diagram - Scenario of using the Aggregator

Steps of the Scenario:

1. The user logs into the system.
2. The user performs a search by giving a keyword. Advanced searches can be performed by using the “Tag Cloud”, by choosing only some of the supported social networks etc.
3. The aggregator searches all the available social networks.
4. Search results are returned to the user. The results are updated in real time.
5. The user chooses a record that she wants to follow.
6. The aggregator performs the action on behalf of the user
7. The corresponding social network returns a response to the request.
8. The aggregator informs the user about the result of her request.

In order to perform the log in, the user must have been registered with our system. The scenario of the user registration is shown in the sequence diagram below:

Sequence Diagram - Log in Scenario

Steps of the Scenario:

1. The user performs a registration giving her username, password and credentials of the FB, Twitter and Linkedin social networks.
2. The aggregator checks the credentials that the user gave for the different social networks.
3. The aggregator searches all the available social networks.
4. The aggregator informs the user about the result of the registration.

Storyboards

Finally, a storyboard-like figure that shows the user interface of the system.

Storyboard - Aggregator UI (Sample Web Page)

The Google-like appearance was chosen because it is very familiar to users of the Web. It has been proven both simple for new users and practical for those who have experience in using such systems.