信用卡帐户(帐户)可以属于多个客户,一个客户(客户)可以拥有多个信用卡帐户。我需要设计REST API,它可以返回客户拥有的所有帐户。帐号来自最终用户的手动输入,如服务代表到自由格式文本框。以下是约束
最终消费者/开发者只知道帐号&不提前了解客户ID (客户的唯一标识符),以便检索属于客户的帐户列表 -
1.1找到拥有相关帐户的客户
1.2然后查找客户拥有的所有帐户。
我可以想到几个选项,但感觉他们会让互动变得更加漂亮或者可能不会让人感到安宁。
以下选项
中仅讨论了GET场景选项1
理想与两个独立资源互动的方式,但会使互动非常繁琐,并会给系统带来不必要的负担。每次两次调用以了解客户拥有的所有帐户。因此,SOAP / RPC中的每天2000万次呼叫将成为REST中的4000万次呼叫。
/accounts/{account_nbr}/customers --> returns a list of customers for a specific account
/customers/{customer_id}/accounts --> returns a list of accounts for a customer
选项2
我认为这不会是宁静的,因为查询参数应该用于识别非人类数据中的资源
/customers/accounts?account_nbr = XXXX
选项3
此选项表示正在返回链接到account_nbr的帐户列表,这是不正确的,因为帐户列表链接到客户
/accounts/{account_nbr}/linked_accounts
选项4
将客户与帐户之间的关系定义为新类型的资源。它试图指示获取客户与帐户关系的列表,并确定customer_account_relationships中的帐户的值为XXXX的特定实例。 / customer_account_relationships?account_nbr = XXXX或
上述哪个选项(如果有的话)接近于表示宁静?有没有其他方法来设计这个界面?
修改
预期回复
{
"customerName" : "Bob",
"customerId" : 1234,
"listOfAccounts": [
{
"accountNbr" : "abcd"
"accountType": "creditcard"
},
{
"accountNbr" : "qrst"
"accountType": "creditcard"
}
]
}
答案 0 :(得分:0)
您正确拒绝了前三个选项。我看到两个合理的选择。一个是选择4:
GET /customer-summaries?account-number=<account-number>
另一种方法是让/accounts
达到顶级水平,并做同样的事情:
GET /accounts?same-owner-as-account=<account-number>
在前一种情况下,您将获得上述资源的实例。在第二个帐户中,您只需获取一个帐户列表,其中每个帐户都可能包含指向帐户所有者的链接。由您决定哪种更适合您的使用案例。
请注意,如果同一帐户有多个所有者,则选项4可能会返回多个记录。这对已婚夫妇来说是一种常见的情况。