产品经理在开发人员的帮助下定义产品的功能。然后将这些功能制定为 API。该 API 本身就是一个产品。
这就是API优先方法。
具体来说,此 API 将允许您交付产品经理想要提供给最终用户的 UI(我们可以将其视为默认 UI)。
而非API优先则是:
作为开发人员,产品经理会为您提供包含屏幕和交互的演示文稿。根据此演示文稿,您然后去设计您的软件。您可能需要一些 API 让客户端与您的服务对话,但这些将是您工作的副产品。
例如,假设产品经理提供了一个描述 TODO 列表的演示文稿。根据此演示文稿,您将定义实现此特定产品所需的 API(添加任务、删除任务)。你的 API 可能是这样的:
Task { id: GUID, content: String, done: Boolean} |
如果在API优先方法中,产品经理将定义 TODO 列表的功能,同时考虑超出即时需求的各种用例,并与竞争对手提供的 API 进行比较。然后,这些功能将被制定为任何人都可以使用的 API。在这种情况下,该 API 应该是这样的:
Task { id: GUID, content: String, done: Boolean, created_date: Date, updated_date: Date } |
新的API与以前的 API 有何不同?
- 添加了创建和更新的日期
- 能够在一个“全部添加”中添加多个任务
- 列表添加了过滤功能
- 添加了事件
现在,显然您可以考虑更多功能,例如将内容更改为 RichText,但具体添加上述功能并不会强制产品支持作为 UI 一部分的其他功能(如 RichText 所需要的),但它们确实提供了超越只需要一个简单的 TODO 列表。
详细点击标题
API first 是一种很好的方法,可以轻松地进行内部和外部集成。然而,它需要技术工具来协助这个过程,员工的思想转变,以及随着时间的推移这将为您的公司提供巨大价值的理解。