你的服务不应该是你如何存储数据的反映。事实上，许多人认为这是一种反模式或不好的实践。

现在设计API服务层有两种流行的趋势/模式(还有许多我不在这里提到的)

面向服务(SOA)

这将引导您按照业务域/功能或类似的东西对服务进行分组。它也将是任务/行动导向的。因此，每个服务都包含系统应该执行的操作和任务。

例子

例如，如果我正在开发一个电子商务系统，我将创建这些服务:

• 安全性(针对用户、组、注册、登录、密码丢失等)
• 目录(产品、库存、评审等)
• 订单(新订单、订单状态、取消等)
• 履行(运输、更新库存等)

面向资源(RESTful)

在此架构中，您将设计服务，就好像它们提供对资源组的访问(但不是显式地提供活动，动作，命令等)

HTTP协议用作通信层，因此每个资源都有其URI/N，并且执行HTTP操作来控制该资源(GET用于查询， POST用于插入， PUT用于更新， DELETE等)

例子

使用上面相同的电子商务案例，下面是在RESTful服务体系结构中的样子:

• 用户(所有CRUD操作)
• 产品(所有CRUD操作)
• 产品评审(所有CRUD操作)
• 订单(所有CRUD操作)

更多RESTful API的详细示例可以在SpreeCommerce和Shopify找到，以及他们如何构建他们的API端点。

这种架构最近越来越流行并被广泛接受，主要是因为它允许后端支持多个客户端应用程序(想想Web和Mobile)，但要注意，它将迫使你将大部分系统开发/编码转移到客户端(Web应用程序/站点的情况下是HTML/JS)

我还鼓励您阅读更多关于SOA以及其他设计和架构模式的内容。虽然我不推荐特定的阅读材料。

编写API时需要考虑的事项

• 记录好你的API。使用一个直观的工具，比如Apiary和他们的底层技术API Blueprint

• 为您的API使用自动化测试工具。最好它能从你的API文档中读取用例，并基于它们生成单元测试(这可以使用API Blueprint技术，无耻插头:asp.net的API Blueprint主机可以帮助使用它的文档模拟API)

如果我的数据库中有20个表，我是否必须创建20个Api控制器

。你只需要一个控制器来实现它所需要的功能。储存的方式和位置并不重要。当你有一个提供与下订单相关的方法的控制器时，它通常会与许多表(客户、库存、产品、发票、订单、订单线、运输等)交互。