为这么一个成果实现API：用户在电商网站可以点击某产品，向系统倡议一个请求，系统按照商家预定的法则或者大数据，孕育产生一个组合产品供消费者选择。用户的请求需要记录，以供以后为客户做更精准的推送。
按照需求，设计了一个RESTful气势派头的 API，下面的例子为便利探讨，删去了部分字段。
Request: POST /deal-requests { "customerId": "jboss", "productSku": "123" } Response: 201 created { "id": "1101", "customerId": "jboss", "productSku": "123", "deal": { "id":"2001", "price": 200.00, "productSkus": ["123", "124"] } }
先后有两位同事提出贰言，不理解为何这样做。一种更直白的方案应该像这样：
Request: POST /get-deal { "customerId": "jboss", "productSku": "123" } Response: 200 ok { "id": "2001", "price": 200.00, "productSkus": ["123", "124"] }
看起来很容易理解，倡议一个getDeal的请求，然后返回一个deal内容。但这种并不切合RESTful气势派头。至于是否必然要用RESTful气势派头，是此外一个话题，假设我们是要做一个RESTful气势派头的API。
RESTful是以资源为中心的，这也决定了一个API的URL。那么这个AP应该对应的是哪一个资源？
Client是想获取deal资源的，如果client知道是哪一个deal的话，好比id=2001， 那么可以通过标准的GET要领来获取该deal的详细信息
GET /deals/2001
可是client并不知道要返回的是哪一个deal，这个是由server真个逻辑来决定的。甚至在client发出请求的时候，这个deal东西可能还不存在。那么是否该
POST /deals { "customerId": "jboss", "productSku": "123" }
这看起来是一个标准创建deal的API，但是并不包罗创建一个deal所需要的信息，如这个deal的price和相关的产品信息productSku。
没有必须信息怎么能创建一个新的资源呢？
别的，我们的deal也可能是由一个外部引擎或者此外一个处事来孕育产生，如果我们需要供给一个API来生存这些外部系统生成的deal资源，我们就不能再使用标准的格局来创建deal了，因为我们不能通过body中的内容来区别API。
POST /deals { "price", 200.00, "productSkus", ["123", "124"] }
颠末分析，我们发明应该还存在一种deal-request资源，，包罗customerId和productSku属性（实际上还有时间属性）。这些信息我们也是要求记录下来的，以供系统学习使用。
deal-request资源还有一个重要的属性就是，和其关联的deal资源。这也是在我们的场景中client需要使用的信息。Client并不卖力分配哪个deal资源给deal-request，更不用去关心这个deal是如何孕育产生的。这个由Server来完成，可能是按照deal-request信息当即计算孕育产生的；也可以由专有处事提前孕育产生了一批放在pool中，然后从中拔取一个和deal-request关联。
所以过程酿成了：Client发出一个deal-request创建请求，server答复201创建告成，并返回deal-request资源，里面包罗了关联的deal资源。这样理解下来API就清晰了。
识别资源是RESTful API设计中的重要事情。我们往往会采纳对照直白，容易实现和理解的设计，制止过度设计。但跟着成长，系统慢慢就陷入了混乱，因为一开始我们并没有深条理的分析清楚。实际上改正确的做法是抓住问题的素质，才华连结简单和不变。