SmartThings has been consistent about saying:
The reasoning behind this architecture is that, like SmartApps that run entirely in the SmartThings Cloud, external web services should only have access to the explicit security context that is set up by the user.
I am not sure I understand the motivation and limitations of this; but my experience with open API’s to proprietary web-services is limited.
I can’t understand why “full” (or “nearly-full”) front-end API access can’t be granted, because other companies seem to be able to do this in other contexts:
Examples (some of which may make no sense in this context, but I’m grasping…) – as done through access tokens:
- Login/authentication services from Facebook, Google, etc.
- API's to access GDrive, Dropbox.
- Use of GTalk (google communication layer), for VPN's and integration into other chat clients and more.
- Others: ? ... maybe the community here has many other applicable examples?
I have two personal motivations that are driving my concern on this topic:
- The current GUI has significant design elements that I disagree with. I'm sure some will be improved/evolved by SmartThings (e.g,. landscape orientation, web GUI, ability to put a Thing into multiple Groups like icon shortcuts (soft-links) in Windows, SmartApps having the ability to call other SmartApps, calling a SmartApp directly from a tile (not just subscribing to an event), ...); but a lot of this official current "look-and-feel" will likely persist, I presume.
- There are many competing (and complementary) home automation / connected "thing" ecosystems coming online soon (various Kickstarters and new products from established vendors). Many of these are providing their OWN clouds and front-end mobile apps; different APIs, rule languages, etc..
- As a result of 1 & 2: I would like to know that we could have the ability if desired to code our own UI's (and expanded APIs) such that we can maximize the ability to quickly innovate and integrate: I'll bet there are a few dozen members of the "Developer Community" who could program a workable web based front-end UI to SmartThings in just a few weeks, if given full access to the API. This GUI might not look anything like the SmartThings mobile UI... but that is not necessary a bad thing. It would not take away the ability for ST to provide their own official web UI; let the customer's choose which to use (or buy, or integrate with competitor's, ...).
But, also, again, again … I perhaps am just not clearly understanding specifically WHAT is or is planned to be exposed and documented in the official public API’s, and which extra stuff that official “partners” will get (and how to become a partner!?!), and what stuff will never be exposed.
Well… After writing all of the above, I went back and skimmed this document; and it is helping me understand the environment a bit more and I am a little bit more optimistic.
EXCEPT: Well… the document has a lot of sections with no information in them yet. 
Is there an update?
Thanks!
…CP.