在RESTful web服务中，在有效负载或响应体中使用JSON文本值（字符串/数字）作为输入参数是否可取？
如果我有一个端点PUT /mytodolist，它可以接受请求负载中的JSON字符串文字值"Take out the rubbish"吗（使用Content-Type=application/json），还是应该接受JSON对象（{"value":"Take out the rubbish"}）？
类似地，GET /mytodolist/1在响应体中返回"Take out the rubbish"可以吗？还是应该返回正确的JSON对象{"value":"Take out the rubbish"}
Spring MVC使实现和测试这样的端点变得容易，但是客户端已经将其标记为非标准或难以实现。在我看来，JSON文本是JSON，但不是JSON对象，所以我认为这很好。我没有发现使用谷歌的推荐。
第1版：敲诈勒索
这个问题完全是关于"标准"的，如果它允许与否。
我理解可扩展性的问题，但永远无法设计出完全可扩展的接口IMHO。如果需要进行更改，我们可以尝试以向后兼容的方式扩展我们所拥有的内容，但会在某个时候变得混乱，需要其他方法-通常通过以这样或那样的方式对API进行版本控制来处理。尽管如此，我还是觉得这是一个公平的观点，因为使用文本作为请求/响应主体会立即变得不可扩展，而提出一个合理的单属性JSON对象则不会。
还可以理解的是，一些框架在处理JSON文本时存在问题，这就是这个问题的根源。我使用的工具恰好支持这一点，所以我认为这是可以的，但前端库没有。
尽管如此，我现在想弄清楚的是，使用JSON文本是否符合事实上的标准（即使它是一个特例）。
我建议始终使用JSON对象。一个原因是，对于Content-Type应用程序/json，人们期望以"｛"开头的内容，而不是所有框架都能正确处理json文本。第二个原因是你可能会在列表项中添加一些额外的属性（截止日期、类别、优先级等）。然后，你会通过添加新字段来打破向后兼容性。
在您的示例中，这可能是可以接受的，但请记住，明确的接口更容易使用，这将鼓励采用。
例如，您的接口可以将"Take out he rubbish"解释为与{task:"take out the rubbish"}相同，但一旦添加了其他属性（例如"when"或"who"），请求中单独字符串的含义就会变得不明确。随着接口的成熟，您将不可避免地添加对新属性的支持。