61–70 of 77 posts
Along these lines, I've been thinking of a building a business around building APIs for small businesses. I'm thinking of local mom and pop grocery stores, local restaurants, my dry cleaner, my car wash guy, etc. Imagine a world where all businesses offered an API to interact with them.
What would an API for a mom and pop grocery store do and who would use it?
http://en.wikipedia.org/wiki/Electronic_data_interchange
Admittedly they're not perfect, but "hackers" weren't the first ones to think of automating back office processes. Most invoicing, payables, receivables etc. happen over these protocols.
Naturally these functions will probably eventually move to REST over time as the broader enterprise software ecosystem moves in that direction, but it's not like wild uncharted territory.
Bottom line, it's amazing how easy it has been rebuilding the front-end when the original app was already built from a backend API. I don't think we purposely knew how future-proof we were making our server APIs.
Now days I thought this was an obvious choise. Even if the API is for internal applications.
Earlier quoted context omitted.
This is a very interesting idea - a formalized representation of contact information would help a lot in fighting the walled-garden effect of Facebook/etc. Unfortunately, as currently implemented, this seems to be yet another centralized service that that is a single point of failure. Would you consider taking a moment to write up a (draft) protocol first? Core features of the internet (representation of personal met…
Admittedly, I was in something of a rush to throw it together, and altogether skipped that step. As you'd expect, the result was a bunch of second guessing, and false starts. That said, I'm absolutely trending that direction, but I felt like there was enough that I didn't know that attempting a spec out of the gate would have led to a bad spec and a bad implementation, and the way that I've always worked, it's easier…
Along these lines, I've been thinking of a building a business around building APIs for small businesses. I'm thinking of local mom and pop grocery stores, local restaurants, my dry cleaner, my car wash guy, etc. Imagine a world where all businesses offered an API to interact with them.
On one hand, you may discover (as I fear) that mom-and-pop don't need an API or don't have the resources to pay for one. Perhaps even if they did, nobody would use it.
On the other, you may conveniently find yourself with the first few customers you'll need. They'll already know and trust you, and you'll have very clear idea of what their challenges are.
The final sentence in the article really struck a chord with me... > Where there is paper to push, a call to answer, or a purchase to approve, there is an API coming to replace it. I've made a pretty decent living in life by following the old mantra that anywhere you see an Excel spreadsheet being used in a business process, there's an opportunity to exploit. That idiom has now moved even further, at this point, and…
Seems most useful for information that changes often. Say, for example, you move around a lot and I want to know when you're in town. I could poll your API (and others like you) and see who's in town this week. Or maybe, as a freelancer it could be used to signal that you have free time. And the consumer could then find 5 rails programmers, who also know whatever , with at least a week of free time coming up.
Further, I see a distinction between Personable (the site) and the "Personal API", is that I see Personable as also having services that actively monitor other social sites and update Personable automatically. Checkins to Foursquare, Facebook, etc could be automatically read in to Personable, which would show your 'current location' as whichever the most current update is, regardless of which provider you used.
Same thing with RSS feeds, Youtube videos, etc., etc.
Perhaps not much of a distinction, but that's my thought process anyway.
This is incredibly interesting. According to some people we're looking at unprecedented growth in the space. Right now there's roughly 9k public APIs. By 2019 that number could be over 100,000. The question becomes though who does the integrations? Not everyone is a developer. The world needs plumbers for toilets and electricians for lights. I think the future of web development looks a lot like these industries. If…
I think the answer to that lies in HTTP discovery protocols. I'm imagining self-organizing applications based on the need of the user, wiring together representations of disparate data sources into a cohesive interface. You shouldn't have to be a dev to take advantage of the API universe. You'll just need tools that are able to reason about the data available.
Along these lines, I've been thinking of a building a business around building APIs for small businesses. I'm thinking of local mom and pop grocery stores, local restaurants, my dry cleaner, my car wash guy, etc. Imagine a world where all businesses offered an API to interact with them.
In fact, location is already supported by Google: https://support.google.com/webmasters/answer/146861?hl=en
Armed with APIs, developers will drive the composable enterprise http://gigaom.com/2013/10/12/armed-with-apis-developers-will... SUMMARY: The rise of APIs as a source for web services and data means that developers don’t have to reinvent the wheel on every feature — they can source it from an API. This trend brings about the composable enterprise.
There's always the danger of relying on APIs that are subsequently retired with little notice though.
Depending on what data you are trusting the APIs with there is also the security risk. CirleCI have just suffered from MongoHQ's security failure in a way that is extremely urgent and customer affecting.