Pure API Community Front End - RFC

API authetication (without SSO)

From your AppServer (e.g PHP or Ruby) your code accesses the Rest URL supplying your username and password which returns you the session token for that user account. You must present this session token in subsequent Rest calls for access to functions / data that are available to this user role. The session key will expire after 30 minutes of inactivity.  

Rest URL: http://community.lithium.com/community-name/restapi/vc/authentication/sessions/login

Lithium Docs: http://community.lithium.com/t5/Community-API/bd-p/developers-rest-api?leaf-id=AuthenticationManager.sessions.login#AuthenticationManager.sessions.login

API authentication (with SSO)

Your AppServer must first retreive the SSO token from the SSO system using whatever mechanism is required (username/password etc). 

The process from here is much the same as without SSO, your AppServer code accesses the Rest URL supplying the SSO token which returns you the session token for that user account. 

Considerations / Issues

• A session token is only required to access operations that require you to be logged in (like Kudo'ing something). 
• Calls to the REST API without a session token are considered to be anoymous and generally are the same as accessing Community directly while being logged out. 
• Its been documented here before that performing activities via the REST API with a user session token may/ does not update the users metrics, such as Post, Kudo and view counts. (?). 

Not sure why you would do that ... do you think it would be faster?

As for caching, there is an article here.

In no particular order;

Limitations related to using multiple skins / themes within Studio (there are many)

Improved Content Management, since custom content, custom settings are overloaded and not ideal

Improved User Experience with better / tighter integration into existing websites

Break out of the Stage to Production release process into a more Agile process

Improved SEO with tailored HTML (consider Lithium uses a H1 for the OP and also replies)

Having content attributed to the correct domain by Google and other Search Engines (not the sub / parked domain)

Improved performance (perhaps)

I can go on ... 

But really because we can and should be able to :)

I have created a proof of concept API-driven interface (not hosted on Lithium), so it is definitely achievable.

I decided to use AngularJS and Twitter Bootstrap to avoid as much boiler plate code as possible. I use it to monitor for new messages on Lithosphere (when I have the time :smileyhappy: ) - it asynchronously loads individual messages when I click on the subject, and I can reply in-line.

Interestingly, this is the same approach Lithium are taking with Mobile v2 - it is driven by APIv2 and you'll be able to customise almost any part of the interface. You can see it in action on the mobile version of this community - have a look at the HTTP requests it makes.

Hi Nathan

Thanks for the reply, indeed we have also seen the Mobile V2 work and the V2 API calls. We've dabbled with this type of thing also when building Community widgets outside of Lithium.

However there are caveats and some operations (such as those you find in the Topic Options drop-down that are not possible via the API (yet in V2). We intend to explore these and document them here. We'll also prioritise these (maybe via Ideas) and hopefully get Lithium to address the critical ones in expanding the V2 API.

Being able to quickly build out a light-weight front end that supports 80% of Lithium functions such as navigate, read, reply, post, kudo, tag, mark solution, label, subscribe, read / unread, search et. al. means we can tailor ad-hoc community channels without having to create complete Lithium themes / sub-themes.

Updates soon..