Dennis works at 99designs, and in this article he describes the choices, experiences and takeaways from building an API to complement the new Tasks service.
Dennis在99designs工作 ,在本文中,他描述了构建API以补充新的Tasks服务时的选择,经验和收获 。
“Wanna see something cool?”
“想看看很棒的东西吗?”
Two years ago my boss, Lachlan, came to me with a secret side project he'd been hacking on for getting small design tasks done quickly. The idea was for customers to submit a short design brief that would be matched to a designer who's waiting and ready to go.
两年前,我的老板拉克兰(Lachlan)带着一个秘密的副项目来到我这里,他一直在忙于Swift完成小型设计任务。 该想法是让客户提交简短的设计摘要,以与正在等待并准备就绪的设计师相匹配。
We assembled a small team and spent the next two months working like crazy to get an initial public release out and prove it was something people wanted.
我们组建了一个小团队,并在接下来的两个月里疯狂地工作,以进行首次公开发布并证明这是人们想要的。
Lachlan's original vision included the idea of an API for graphic design work along the lines of Amazon's Mechanical Turk—but more beautiful and tailored specifically for graphic design.
拉克兰(Lachlan)的最初愿景包括按照Amazon的Mechanical Turk的思路进行图形设计工作的API的想法-但更为美观,并且专门为图形设计量身定制。
![Screenshot of the Tasks home page](https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2015/06/1435654989tasks.jpg)
We've continued to refine 99designs Tasks as a consumer service, but the vision of an API for graphic design continued to stick in our minds. We just weren’t quite sure if it was worth doing or not.
我们一直在完善99designs Tasks作为一项消费者服务,但是图形设计API的愿景仍然牢记在我们的脑海中。 我们只是不确定是否值得这样做。
转折点 (A Turning Point)
Then we were caught by surprise. We discovered that our friends at Segment had built an automated tool using PhantomJS, which screen-scraped our website to work around the fact we hadn’t built an API yet!
然后我们被惊喜所吸引。 我们发现, Segment的朋友已经使用PhantomJS构建了一个自动化工具,该工具对我们的网站进行了屏幕筛选,以解决我们尚未构建API的事实!
I’ll admit—it was pretty embarrassing to be beaten to the punch by a customer on an idea we’d been thinking about for two years. On the other hand, there's probably no better way to validate an idea than to have a customer do it for you.
我承认-在我们考虑了两年的想法上被客户打败真是令人尴尬。 另一方面,验证一个想法可能没有比让客户为您做更好的方法了。
好,让我们这样做 (OK, Let’s Do This)
We quickly realized that developing an API would involve more than just the technical design and implementation. The audience and concerns of an API are very different from anything we’d worked on before.
我们很快意识到开发API不仅涉及技术设计和实现。 API的受众和关注点与我们之前所做的任何工作都大不相同。
界定范围 (Scoping It Out)
One of the first challenges we faced was figuring out what features we wanted in an API. We already had a few API customers that needed a fairly specific feature set for creating tasks—but we wanted to open up the possibilities and allow ideas we hadn’t even begun to think of yet. We made the decision to expand the scope beyond task creation to cover the entire task workflow in order to enable a wider set of possibilities.
我们面临的第一个挑战是弄清楚我们想要API中的哪些功能。 我们已经有一些API客户,这些客户需要用于创建任务的相当特定的功能集-但是我们想开放可能性,并允许我们甚至尚未开始考虑的想法。 我们决定将范围扩展到任务创建之外,以覆盖整个任务工作流程,以实现更多的可能性。
开发人员行销 (Developer Marketing)
Another big question we faced was how to market an API? Our customers are typically entrepreneurs and small businesses. The target audience of an API is very different from what we're used to.
我们面临的另一个大问题是如何销售API? 我们的客户通常是企业家和小型企业。 API的目标受众与我们以前所用的完全不同。
There's a saying that "if you build it, they will come", but I'm not convinced it's quite true. We knew there was some hard work to be done if we wanted to attract developers. There are a few questions that developers might ask when looking at an API:
有一种说法是“如果您建造它,它们就会来”,但是我不相信这是真的。 我们知道,如果我们想吸引开发人员,则需要做一些艰苦的工作。 开发人员在查看API时可能会问一些问题:
"Why should I be excited?"
“我为什么要兴奋?”
"What are the benefits?"
“有什么好处?”
One strategy we had for attracting developers was to have a collection of compelling examples that would inspire new ideas. The problem is that building these examples requires us to attract developers to build them in the first place. We tackled this chicken/egg problem by working with a group of launch partners in a private beta ahead of our public launch to build some great quality applications that we could show off.
我们吸引开发人员的一种策略是收集一些令人鼓舞的示例,这些示例可以激发新的想法。 问题在于构建这些示例需要我们吸引开发人员首先构建它们。 我们通过在公开发布之前与一群发布伙伴合作进行了私下Beta测试来解决此鸡肉/鸡蛋问题,以构建一些我们可以炫耀的高质量应用程序。
We also applied a "dogfooding" approach at 99designs, where our development team worked on a number of app ideas internally—including a browser extension and a chat bot, all of which used our in-development API.
我们还在99designs上采用了“折衷”的方法,我们的开发团队在内部处理了许多应用程序构想,包括浏览器扩展和聊天机器人,所有这些都使用了我们的开发中的API。
开发人员入职 (Developer Onboarding)
Part of attracting the best developers means making it super easy for them to get started. There’s a few aspects to this that can help get developers going.
吸引最优秀的开发人员的一部分意味着使他们上手超级容易。 有几个方面可以帮助开发人员继续前进。
1.文件 (1. Documentation)
It’s really important to have well written documentation to help developers understand what the API does and how to use it. This means having accurate and up-to-date reference documentation. It also means having plenty of how-to guides, tutorials and code examples.
拥有写得很好的文档来帮助开发人员了解API的功能以及如何使用它,这一点非常重要。 这意味着拥有准确且最新的参考文档。 这也意味着拥有大量的使用指南,教程和代码示例。
2.社区与支持 (2. Community and Support)
Attracting the best developers also means helping out when they have questions. We’re hoping to foster a community around our API, which will mean some outreach and advocacy. This can include channels like mailing lists, forums and chat. It also means getting the word out and telling developers about your API—like the post you’re reading right now!
吸引最好的开发人员还意味着在遇到问题时提供帮助。 我们希望围绕我们的API建立一个社区,这将意味着一些宣传和倡导。 这可以包括诸如邮件列表,论坛和聊天之类的渠道。 这也意味着要广为宣传,并向开发人员介绍您的API,就像您现在正在阅读的帖子一样!
![Tasks API on GitHub](https://i-blog.csdnimg.cn/blog_migrate/31105011f72ab2378b182110d92c7e60.webp?x-image-process=image/format,png)
3.熟识 (3. Familiarity)
It’s important to make our API as familiar to developers as possible, which means following industry standards and trends. We did some investigation into different styles of API (e.g. REST vs RPC)—and what we found surprised us.
确保开发人员尽可能熟悉我们的API,这一点很重要,这意味着遵循行业标准和趋势。 我们对不同样式的API(例如REST与RPC )进行了一些调查,结果使我们感到惊讶。
One of the RPC libraries we investigated was a library developed by Facebook, called Thrift. We heard out about Thrift from one of our partners that had used it pretty successfully already. We liked the strict data typing and interfaces, and the client and server code generation was quite compelling.
我们研究的RPC库之一是Facebook开发的名为Thrift的库。 我们从已经非常成功使用它的合作伙伴之一那里听说过Thrift。 我们喜欢严格的数据类型和接口,并且客户端和服务器代码的生成非常引人注目。
On the other hand, REST is a massive, almost overwhelming industry trend. What we found, though, is that there’s still some debate about how to do REST “properly”. We were a bit surprised that the tools and standards for building REST APIs are still immature and inconsistent in places—even though it’s a far more popular style.
另一方面,REST是一个巨大的,几乎是压倒性的行业趋势。 但是,我们发现,关于如何“正确”执行REST仍存在一些争论。 令我们感到惊讶的是,即使在某些地方,用于构建REST API的工具和标准仍然不成熟且不一致。
It feels like the industry is suffering a mild case of “Not Invented Here” syndrome. Many REST APIs invent their own custom schemes and headers for things like authentication and request signing, as well as inconsistent use of HTTP verbs and status codes. It seems to be one of those cases where “worse is better”.
感觉该行业正在遭受“此处未发明”综合症的轻微发作。 许多REST API发明了自己的自定义方案和标头,用于身份验证和请求签名,以及HTTP动词和状态代码的用法不一致。 这似乎是“越差越好”的情况之一。
Despite the downsides, we decided to go with a REST style, because it’s a style that’s very accessible and easy to get started with, which really counts for a lot.
尽管有不利因素,我们还是决定采用REST风格,因为它是一种易于访问且易于上手的风格,这非常重要。
支持API:客户的客户就是您的客户 (Supporting an API: the Customer of your Customer is your Customer)
In addition to supporting our partner developers, we also need to make sure that our partners can support their own customers effectively. 99designs is pretty obsessive when it comes to customer support. But if customers are using 99designs Tasks via a partner API integration—it’s not really appropriate for us to step in on customers that aren’t ours. However, things go wrong sometimes, so we need to be prepared for problems.
除了支持我们的合作伙伴开发人员,我们还需要确保我们的合作伙伴可以有效地支持自己的客户。 在客户支持方面,99designs非常吸引人。 但是,如果客户通过合作伙伴API集成来使用99designs任务,那么我们真的不适合接触非我们的客户。 但是,有时情况会出错,因此我们需要为问题做好准备。
“I need my website redesigned in an hour.”
“我需要在一个小时内重新设计我的网站。”
“This is too much work.”
“这是太多的工作。”
We have to trust our partners to support their customers how they choose, so we’ve provided tools to help take care of this. In practice, this has meant including webhook event notifications for when customer support needs to get involved.
我们必须信任我们的合作伙伴,以支持他们的客户如何选择,因此我们提供了工具来帮助您解决这一问题。 实际上,这意味着在需要客户支持参与时包括webhook事件通知。
下一步是什么? (What’s Next?)
One of the biggest upcoming challenges is full support for international customers. The challenge begins with language translation and payment in local currencies—all the way through to how we match customers to the designer that's right for them.
即将到来的最大挑战之一是对国际客户的全面支持。 挑战始于以当地货币进行语言翻译和付款,一直到我们如何使客户与适合他们的设计师匹配。
摘要 (Summary)
If you’re thinking about building a public API for your product, here are five things you should consider:
如果您正在考虑为产品构建公共API,则应考虑以下五件事:
- There’s more to building an API than building an API. 构建API不仅仅是构建API。
- Launch partners are your friend. 启动合作伙伴是您的朋友。
- Build your API to be as easy to use as possible. 构建您的API以使其尽可能易于使用。
- Problems are more complicated when dealing with customers of customers. 与客户打交道时,问题更加复杂。
- Be open to imaginative app ideas you weren’t expecting. 对未曾想到的富有创意的应用程序想法持开放态度。
We’re really excited for the possibilities that an API for graphic design will enable. We’re currently in private beta. If you’re interested in partnering, please get in touch!
我们为平面设计API启用的可能性感到非常兴奋。 我们目前处于私人Beta版。 如果您有兴趣合作,请联系!
翻译自: https://www.sitepoint.com/lessons-learned-developing-the-99designs-tasks-api/