RESTAPI:在POST/PUT/GET中使用ID与实际值

RESTAPI:在POST/PUT/GET中使用ID与实际值,api,rest,design-patterns,asp.net-web-api,Api,Rest,Design Patterns,Asp.net Web Api,我正在设计API,以允许客户使用POST/PUT/GET管理他们的数据 API面临的挑战之一是,实体中有许多字段应该具有来自预定集合的值。 我看到的方法之一是允许客户端为每个数据字段(属性)传递ID,并有一个补充方法为客户端提供数据字段的可用选项。 因此,客户端与服务的交互将是: 客户端:GET\Options(返回每个字段的可用选项集) Client:POST\Data(发送带有每个属性的ID集的DTO,这会将数据保存到服务器) 我看到的另一个选择是让客户端发送实际值,而不是ID 你推荐什么方

我正在设计API,以允许客户使用POST/PUT/GET管理他们的数据

API面临的挑战之一是,实体中有许多字段应该具有来自预定集合的值。 我看到的方法之一是允许客户端为每个数据字段(属性)传递ID,并有一个补充方法为客户端提供数据字段的可用选项。 因此,客户端与服务的交互将是: 客户端:GET\Options(返回每个字段的可用选项集) Client:POST\Data(发送带有每个属性的ID集的DTO,这会将数据保存到服务器)

我看到的另一个选择是让客户端发送实际值,而不是ID


你推荐什么方法?为什么

让客户端将数据作为值传递,但将数据作为外键存储在服务器上

假设您设计了一个用于添加汽车的API,汽车颜色应该是来自预定集合的值

HTTP请求:

GET cars/1
=> 200 OK
{ id: 1, name: "Ferrari", colour: "Red }


POST cars
{ name: Lamborghini, colour: "Blue" }
=> 201 Created (cars/2)
数据库(只是一个示例):

…其中Car.colorID是您的color.ID的外键

优点是:

  • 该API易于使用
  • 您仍然保持来自预定集合的数据约束,例如,张贴带有颜色的汽车:“Dog”应导致HTTP响应,并显示错误信息(例如,无效颜色)

  • 是的,但是他希望服务消费者知道所有有效的颜色是什么,所以他需要一个Get/color方法。是的。这是有道理的。我认为可以有两种不同的方法:对于get操作:返回id+value。对于Post/Update-按ID更新。并具有向api客户端提供可用选择选项的附加方法。
    Table [Car]: @ID (Integer) , Name (Varchar) , ColourID (Integer)
    Table [Colour] : @ID (Integer), Name(Varchar)