@ Brian – Thanks for so effectively summarizing Mashery’s strategy so cogently. I couldn’t have said it better myself. You build the API, and when it’s done, we have what you need to release it to the world right away.

To your specific questions:

- A key component of this week’s launch is our API proxy, although we have alternatives to proxying for larger clients who prefer a direct access solution

- You should not need any more DNS entries than you already have, if I undertand your question correctly. You are likely already sending your API calls to a separate domain, such as api.yourdomain.com. That domain would be redirected to us, and we in turn would access your API directly through a private DNS entry used only by Mashery. Should you ever decide to discontinue using Mashery, you would simply point the API domain to your servers or to another service provider.

- We do not currently provide http caching, but we have had several requests for that and expect to provide a solution for that soon. Meanwhile, there should be no issues with using other caching tools. Email us and we’ll work with you to figure out a solution.

At the moment, I am working on a public developers API and your service seems like it could take the place of the authentication/throttling layer we were planning (in addition to the community/support features).

In the interest of boiling mashery down a bit:
– is it simply an API proxy?
– such that I would effectively have two DNS entries?
– does it provide HTTP caching?
– if not, does it at least allow the API to implement HTTP caching?

thanks, and looks promising!

I’m guessing not, but that would be a very useful (and valuable) thing to provide.

As for your suggestion of a “store and forward” approach, we agree that this would be a very useful service, and we’ve discussed where on our development roadmap it should appear. For now, we have launched with a group of services we believe will accelerate the rate at which new APIs are offered for use, and therefore accelerate the development of many new applications. As this market evolves, we will supplement the vendor-focused offering we launched today with new features that take advantage of the breadth of services we manage to address the biggest challenges developers face in creating new applications. The service you suggest is definitely in line with the kind of roadmap we have in mind.

@ Don’t get it – I agree with Rafer, but I’d go on to say I also had the expectation that it would be a straightforward challenge to create the entire group of community management services – blog, wiki, forum, annotated documentation and static pages – with a single sign-on and a consistent user experience – by bringing together existing tools and tweaking the formatting and authentication settings. That turned out to be a fairly significant challenge, and maintaining it as each component evolves would be a headache. We decided it was easier to build a solution designed for this from day one, be able to maintain and improve on it over time, and tie it directly in with our back-end systems that manage developer keys, API access, and other management functions. All of this can be controlled from a single consistent user interface.

Oren Michels, CEO
Mashery

If you’ve designed an API, you want people to use it. If you want a significant number of people to use it, you need to have a rich developer support site. If a lot of people use the API, you need to measure (and possibly limit) its use. Each API provider can either roll all that from scratch, distracting from their core effort, or user Mashery. Mashery’s done it right, and it’s all we do. We’re expecting to be pretty darn good at it.

If you use and API, you want it supported richly and in a reasonably standard way.

How does mashery differ from what Grand Central (the first incarnation) was trying to do?

I do see value in a “store & forward” approach when someone is writing to multiple API’s but rather do one call to mashery and get all the data back in real-time & in the right sequence . . . since many API’s are stateless, you dont have the headache of managing timeouts, exceptions, and re-posts . . .

Matthew – We don’t host them. As Marshall says, we provide community tools, which we do host. But the actual APIs are hosted by the provider, while access to them is managed, metered and reported by Mashery. Hope that explains it.

Oren Michels
CEO, Mashery

Are they going to proxy my app API? As an API provider, why would I want that? As an API user, why would I want that?

Most everything I see at Mashery are things I’d want to avoid…..the rest are things I can get at lots other places.