使用标准REST API相比自行简化实现的PHP接口有哪些优势？

关于header设置的必要性 #

你自己封装的json_response已经做了最核心的两个header相关处理：返回正确的HTTP状态码、设置Content-Type: application/json，这已经满足绝大多数场景的需求了。大家常说的额外header配置的必要性主要对应这些场景：

• CORS相关头（Access-Control-Allow-*系列）：如果你的接口需要给跨域的前端调用，就必须配置对应的CORS头，否则浏览器会直接拦截返回结果，前端拿不到数据；如果都是同域调用或者仅服务端调用就不需要。
• 缓存相关头（Cache-Control、Pragma等）：如果接口返回的是实时性要求高的数据，配置禁用缓存的头可以避免客户端/CDN缓存旧的返回结果，减少业务异常。
• 其他自定义头：比如接口版本标识、签名校验头这类，都是按需配置，没有强制要求。
  整体来说按照规范配置必要的header确实是更优的实现，能减少很多潜在的兼容问题，你的封装已经覆盖了核心逻辑，只需要按需补充场景相关的头即可。

改造为REST规范后能否正常用Fetch API获取结果 #

完全可以，甚至会更方便。REST规范本质只是要求遵循HTTP语义，比如删除操作用DELETE请求、查询用GET请求、新增用POST请求，Fetch API本身原生支持所有HTTP请求方法，只要你的接口处理对应的请求方法、返回正确的header和状态码，用起来会比现在所有请求都传cmd参数区分操作的方式更简洁，不需要额外拼接业务无关的参数，还能直接用Fetch自带的response.ok、response.status等属性快速判断请求状态，减少前端的判断逻辑。

三种实现方式的选型 #

没有绝对的最优方案，完全看你的使用场景：

• 你目前在用的RPC风格接口（统一入口、用参数区分操作）：适合小型内部项目，开发快、调试简单，如果你当前的场景只是给自己的前端、内部服务提供调用，已经完全够用，不需要为了符合规范强行重构。
• REST风格接口：适合中大型项目、对外公开的API，规范统一，第三方开发者接入学习成本低，缓存、鉴权、日志这类通用逻辑更容易做统一处理，现在绝大多数对外公开的API都采用这种风格。
• SOAP：目前基本只有传统企业级系统对接才会用到，比如银行、老旧ERP系统的接口，协议复杂冗余，开发成本高，传输的XML格式体积大，除非对接的第三方强制要求使用，否则完全不需要考虑。

额外建议 #

你现在用$_REQUEST获取参数，会同时接收GET和POST请求的参数，涉及数据修改的操作（比如你示例中的删除逻辑），建议增加请求方法限制，只允许POST/DELETE请求调用，避免GET请求被爬虫、浏览器预加载机制误触发，导致数据被误删，实现成本很低但能规避很大的风险。

内容的提问来源于stack exchange，提问作者user10908799