Question

情景1
在我的Web应用程序中说，有一个用于将员工添加到系统的屏幕。输入员工姓名后，只要用户选项卡，就会根据数据库中的某些逻辑和已存在的记录自动生成员工代码（这是下一个字段）。

现在我想为这个应用程序公开rest API，以便第三方开发人员可以构建它。所以，我将有一个名为/Employee的资源，它将响应GET，PUT和DELETE动词。但是当客户端需要自动填充代码时，这是一个GET操作，它将在什么资源上？我应该制作新资源/EmployeeCodeFor/{Name}还是应该/Employee/{Name}/GenerateCode？如果我使用/Employee/{Name}/GenerateCode那么我的资源是Employee的GET，PUT和DELETE，实际上是/Employee/{Id}？

情景2
这里让我们来看看stackoverflow的帖子。所以我们假设资源是/Post/{Id}。以与上一个示例相同的方式，一旦我跳出Title字段，它就会列出可能重复的问题。

再次根据什么网址我应该得到那些可能重复的内容？

我现在想不出更多场景。但是许多这样的场景可能会出现在现实应用程序开发中。如何以RESTful方式实现它们？

方案1的更新
代码和Id是两个不同的领域。 Id是主键，代码可以跨部门重复，只是为了说明。同样要生成代码，首先应提供名称。因此，如果用户键入名称“FirstName LastName”，则服务器可能会生成FL003作为代码，假设已经有两名员工的名字从F开始，姓氏从L开始说部门。可以根据登录用户识别部门。

Answer 1

允许服务器有机会在新资源中预先填充大量元素的一种方法是

POST /Employees
{with empty body}
=>
201 Created
Location: http://example.org/employee/3443

<Employee Id="3443">
   <Code>E1001</Code>
   <FirstName></FirstName>
   <LastName></LastName>
</Employee>

这使服务器有机会提供默认值。如果您正在寻找一种更加互动的方式让服务器在输入过程中提供反馈，我有另一种方法，但需要更多解释。

Answer 2

情景1

假设您的员工代码是唯一标识符。在这种情况下，为了获得它，您将允许用户完成新员工的任何字段，然后进行POST。服务器将生成代码并使用指向/Employee/{generated_code}的链接响应POST，该链接是新创建的员工的记录。

/Employee上的GET将返回所有员工的列表。 /Employee/{a_code}上的GET将为您提供员工详细信息。

场景2

您可以对/Post集合进行某种查询，例如/Post?title_like={question_title}。 GET /Post?title_like=REST How to将返回包含“REST How to”的所有问题的列表。

在REST API中组织资源（URI）

2 个答案: