Following a link from Stack Overflow, I discovered Embedly and its products.
This is a test using Bookmarklet that generate a card for every web page.
Android RSS Reader Application using SQLite
Android Building Group Chat App using Sockets – Part 2
This is an old post but I think it’s still relevant.
The Bring Your Own Device (BYOD) movement has gained unstoppable momentum. And thanks to the burgeoning mobile app market, employees have high expectations for these tools. They want an attractive user experience tailored to their devices. In other words, companies need to invest in building apps, period.
During the internet explosion, applications settled on three tiers: presentation, logic and data. [..] the lines between the presentation and logic tiers frequently blurred, and a hard border was created between the logic and data tiers.
However, I believe that the overwhelming emphasis on user experience combined with the impact of cloud and big data will now blur the line between logic and data, and the border between presentation and logic will become much more complete. That concrete border has a name: it is the API. That order process now needs to be available on the web and to a variety of mobile devices, so that the logic tier can be accessible to all channels through the API.
source: BYOD is unstoppable. Smart companies must build apps — Tech News and Analysis.
This is my personal list of resources about principles and guidelines for designing RESTful Web APIs.
- API 101 by Kin Lane – a network of sites dedicated to Web APIs and related topics: API Discovery, API Integration, Backend as a Service (BaaS) and much more.
- What Makes a Great API? The Five Keys [19 July 2012] – Valuable slides by ProgrammableWeb’s John Musser presented during a talk at OSCon about the topic of a great API.
- Designing a RESTful Web API [26 February 2012] – Luis Rei‘s article to serve as his personal “quick start guide” for designing RESTful Web APIs. As such, the document is concerned with the how rather than the why. For the latter, check the Bibliography.
- How RESTful is Your API? [26 August 2012] – Thoughts by Cory House about RESTful APIs (pragmatic) implementation following what Roy Fielding outlined in his seminal dissertation on Representation State Transfer (REST).
- Best Practices for Designing a Pragmatic RESTful API [29 May 2013] – when you’re in a position to create a public API for your web app, you’re left with a bunch of choices: What formats should you accept? How should you authenticate? Should your API be versioned? In designing an API for SupportFu, Vinay Sahni have tried to come up with pragmatic answers to these questions. His post contains links and thoughts about this topic.
- The Web API Checklist — 43 Things To Think About When Designing, Testing, and Releasing your API [15 April 2013] – when you’re designing, testing, or releasing a new Web API, you’re building a new system on top of an existing complex and sophisticated system. This is a list of a bunch of things, both obvious and subtle, that can easily be missed when designing, testing, implementing, and releasing a Web API.
- REST, where’s my state? [24 August 2012] – One of the well-known constraints of this REpresentational State Transfer style is that communication must be stateless. This post explains how statelessness works on today’s Web, explaining the difference between application state and resource state.
- Stop Designing Fragile Web APIs [22 April 2013] – When you release your Web API, it’s carved into stone. It’s a scary commitment to never make an incompatible change. If you fail, you’ll have irate customers yelling in your inbox, followed by your boss, and then your boss’s boss. You have to support this API. Forever. Unless you version it, right?
- Building Stripe’s API [28 February 2013] – a post by Amber Feng about designing and building Stripe‘s API, particularly lessons learned and what kind of things they did to try to make the API as easy to use as possible.
- A Software Developer’s Guide to HTTP [12 January 2012] – this is a series of articles where Scott Allen look at HTTP protocol from a software developer’s perspective.
Any company looking to utilize an API to expose its services – and every company should be looking at this – can stand on the shoulders of these giants:
- Use your API as a new channel for your business like Salesforce
- Align your API with your core value proposition like Amazon
- Create a thriving community of developers that use your API like Twitter
- Keep improving your API’s usability like Google
source: 5 lessons from API giants like Twitter and Google
Enterprises however, have to approach their API strategy differently than smaller companies. For startups, getting recognition, traction and customers is most important. Allowing as many people as possible to use their API makes the most sense
For enterprises, the goal is to increase internal efficiency as well as expand brand presence without diluting it. Their API strategy, therefore, has to be segmented.
To tailor an API strategy to their needs, large companies need to think about what data/services they can provide to all of their audiences, then segment accessibility of the API based on the audience.
However, the concept of determining who should have access to your API, depending on how important or sensitive your data is, is applicable to the majority of enterprises.
source: Enterprise Needs for Enterprise APIs