考虑一个名为 Entry 的资源，其端点为：
GET /entries（显示所有条目）GET /entries/<x>（显示条目x）POST /entries（创建新条目）PUT /entries/<x>（更改现有条目x）DELETE /entries/<x>（删除现有条目x）这些我确定。但是如何：
GET /entries/new（显示用于创建新条目的输入表单）GET /entries/<x>/edit（显示现有条目更新的输入表格）这些模式是否也被视为最佳实践？如果不是，那是什么？
答案 0 :(得分：0)
GET /entries（显示所有条目）GET /entries/<x>（显示条目x）POST /entries（创建新条目）PUT /entries/<x>（更改现有条目x）DELETE /entries/<x>（删除现有条目x）一切正常，正如您所料。
GET /entries/new（显示用于创建新条目的输入表单）GET /entries/<x>/edit（显示现有条目更新的输入表格）如果你想保持简单，这两个也可以（它们很常见，大玩家和框架使用，尊重RESTful原则并且有点标准）。
/questions/ask（而不是/new）来显示创建表单; /questions/id/slugified-title查看; /post/<x>/edit显示修改表单。/project/issues; /project/issues/new; /project/issues/<x>;他们没有/edit网址，因为所有编辑都是通过JS就地完成的。为了实现RESTful架构的可伸缩性和松散耦合，有助于根据资源来考虑应用程序。因此，每个URL都应指向不同的资源。所以：
GET /entries/<x>没问题，因为它会返回资源＆＃34;身份<x>的条目＆＃34;。
现在，GET /entries/new也是一种资源，但更多的是＆＃34;实用程序＆＃34;一。只是该地址提供的资源是一个表单（一个解释如何创建条目的文档 - 可能是WADL而不是表单）。
/edit种可能性 GET /entries/<x>/edit，如果你愿意，是我们可以得到的。我们知道，GET返回资源当前状态的表示，而不是（必然）资源。这样，如果资源（当前）可编辑，GET URL将以可编辑的方式返回，否则，它将是只读的（因此不需要/edit资源）。
实现此目标的另一种方法是让GET entries/<x>根据Accept标头返回HTML内容的JSON。这样，如果Accept有text/html，则返回的页面将是包含所有信息的表单（同样，如果资源处于可编辑状态，则表单将是可编辑的。如果不是，然后它将是只读的。
现在我看到这可能不是最佳的，因为您可能不希望每次都显示表单（在GET /entries/<x>上）。如果是这种情况，您将拥有近两种资源：
GET /entries/<x> - 条目GET /entries/<x>/edit - 这个＆＃34;资源＆＃34;将是一个文件，描述客户端如果要编辑条目状态必须进行哪种HTTP请求。在您的情况下，它是一个表单（告诉客户端如何发送或模拟PUT请求），但也可能是一个简短的WADL文件。