Could we not have an endpoint that receives only a single string (like / dislike), without having it encapsulated in a JSON object ? Is it still a RESTful design? (This post suggests that a string is considered valid JSON)
Yes, you can. There is no rule that says that a request payload must be an object, or even that a request payload must be JSON. On the web, many request payloads are application/x-www-form-urlencoded key value pairs.
The trade off is that you can extend the schema of an object by adding more "optional" fields, without breaking backwards compatibility.
Isn’t it a code smell to have a REST endpoint that receives only a single-field information (and, in this case, actually a binary one: true/false)?
Yes - in the sense that a "smell" indicates that there might be a problem somewhere (see https://wiki.c2.com/?CodeSmell ).
There's nothing wrong with having a document that has but a single field of information in it.
Similarly, there's nothing wrong with making such a document available via the web; there's nothing wrong with supporting changes to that document from the web.
Things get a little bit suspicious when you send edits to one resource expecting the effects to show up somewhere else. For example, if we are submitting
POST /api/great_new_feature/feedback
In the expectation that it will change what we see when we
GET /api/great_new_feature
Then that deserves further review, because it impedes the general purpose cache invalidation mechanism built into HTTP. If you are giving up something that is "free", then you better be sure that you are being compensated. In a code review, I would expect to find a decision record documenting the investigation and its findings.
I’m not sure I understand the last paragraph about cache invalidation. Is it specific to an API expecting a single field of information ?
No. HTTP message semantics are part of its uniform interface -- all resources understand messages the same way.
And what is a generally accepted solution to this problem? (I see that the whole website I work on has a Cache-Control: no-store policy)
Ensure that requests that modify information use the same target URI as the requests that read information.
POST /collection
Is a popular choice for introducing new items into a collection because (in part) we expect that the introduction of the new item also changes the representation of the collection itself (typically with a link to the new item).
发布评论
评论（1）
是的，可以。没有规则规定请求负载必须是对象，甚至没有规定请求负载必须是 JSON。在网络上，许多请求有效负载都是
application/x-www-form-urlencoded键值对。权衡是您可以通过添加更多“可选”字段来扩展对象的架构，而不会破坏向后兼容性。
是的 - 从某种意义上说，“气味”表明某处可能存在问题（请参阅https://wiki.c2.com/?CodeSmell）。
文档中只有一个信息字段并没有什么问题。
同样，通过网络提供这样的文档也没有什么问题。支持从网络对该文档进行更改并没有什么问题。
当您将编辑发送到一个资源并期望效果出现在其他地方时，事情会变得有点可疑。例如，如果我们提交
时期望它会改变我们看到的内容，
那么就值得进一步审查，因为它阻碍了通用目的 HTTP 中内置的缓存失效机制。如果您放弃“免费”的东西，那么您最好确保自己得到了补偿。在代码审查中，我希望找到决策记录 记录调查及其结果。
不会。HTTP 消息语义是其统一接口——所有资源都以相同的方式理解消息。
确保修改信息的请求与读取信息的请求使用相同的目标 URI。
是将新项目引入集合的流行选择，因为（部分）我们期望新项目的引入也会改变集合本身的表示（通常带有指向新项目的链接） 。
Yes, you can. There is no rule that says that a request payload must be an object, or even that a request payload must be JSON. On the web, many request payloads are
application/x-www-form-urlencodedkey value pairs.The trade off is that you can extend the schema of an object by adding more "optional" fields, without breaking backwards compatibility.
Yes - in the sense that a "smell" indicates that there might be a problem somewhere (see https://wiki.c2.com/?CodeSmell ).
There's nothing wrong with having a document that has but a single field of information in it.
Similarly, there's nothing wrong with making such a document available via the web; there's nothing wrong with supporting changes to that document from the web.
Things get a little bit suspicious when you send edits to one resource expecting the effects to show up somewhere else. For example, if we are submitting
In the expectation that it will change what we see when we
Then that deserves further review, because it impedes the general purpose cache invalidation mechanism built into HTTP. If you are giving up something that is "free", then you better be sure that you are being compensated. In a code review, I would expect to find a decision record documenting the investigation and its findings.
No. HTTP message semantics are part of its uniform interface -- all resources understand messages the same way.
Ensure that requests that modify information use the same target URI as the requests that read information.
Is a popular choice for introducing new items into a collection because (in part) we expect that the introduction of the new item also changes the representation of the collection itself (typically with a link to the new item).