Symphony Commerce raises $21.5 million in series B funding, plans APIs. Designing a RESTful API to last. Plus: a user's guide to Disrupt SF.
Symphony Commerce Raises Series B Funds, Plans APIs
Symphony Commerce, a provider of commerce as a service right down to warehousing and shipping, has raised $21.5 million in series B funding and plans to launch several APIs. The round was led by CRV. Bain Capital and FirstMark Capital, which participated in the series A funding of $12.2 million, also participated in this one. The API strategy is next.
As Alex Wilhelm reports in Techcrunch, the company is growing quickly and expects to see $1 billion worth of goods moved through its system in 2016:
Looking ahead, Symphony also has a number of APIs in development that will allow developers to tap into its service system, without using its full Stack. Commerce as a service, then, but via an API, so you can use, for example, Symphony’s fulfillment tools only, if that is what you need. The company would prefer if you used its roster of services in unison, of course.
The point behind the tools is that Symphony does the hard stuff entrepreneurs are rarely good at: supply chain management. With its origins in a 2011 Disrupt conference when it was aimed at selling things, this represents a pivot that backers obviously believe in.
Making Your API Useful Longterm: Design, Design, Design
Creating an API is often a lot of work. In addition to the coding, you've got to have your strategy for it figured out--your goals for its use, your monetization strategy, and so on. The longer it lasts the more you will get back from it. What's the secret to longevity? According to Mike Stowe writing on the Mulesoft blog, it's all about design. (Disclosure: Mulesoft is the parent company of Programmableweb.) The post makes a lot of solid points, far more than can be summarized here. But as an example of Stowe's clarity, here's a bit about paying attention to the split between design and development.
With the flexibility RAML offers, APIs can now be developed in two cycles, first the design stage, and secondly, development. As the industry has moved to the agile methodology, APIs have been plagued with the “what do we want to release, and what do we want to change,” mentality. The problem is, once you release your API it shouldn’t be changing, at least not anything that breaks backwards compatibility. Every change you make in your API should be because of a new feature or new requirement… any other change is nothing more than a failure in the design stage. And while it is impossible to be perfect in the design stage, perfection is what we should strive for in order to minimize making any design related changes in the development stage, including output.
The rest of the post evokes that satisfying combination of "that's obvious," with "why didn't I think of that?" And there are some gems, including a discussion about whether making an API complicated is a virtue. Go feast.
API News You Shouldn't Miss
- Create and Run Your Own Real-time Communication Infrastructure with Open Source Matrix.org
- Designing your RESTful API for Longevity The tech behind the GeekWire redesign
- So Many Platforms, So Few Developers
- A User’s Guide To Disrupt SF 2014
- Symphony Commerce Raises $21.5M To Build Out Its Commerce-As-A-Service Toolset
- Destiny – Google Street View in a game world
- Mobile Loyalty Leader SessionM Introduces Rewards for Merchants API