说没有意义，其实还是有点意义的。至少可以防止一些人看到你的请求。
但是，不得不否认的是，这个方法，的确是比较容易被破解。

一般比较严格的校验方法是，首次请求后端时后端返回一个token，此token一段时间内有效。在有效时间内带上此token可返回数据。

具体的token操作可参见我的另一个回答：https://segmentfault.com/q/10...

换句话说，就是接口需要验证，你所说的用个字符串来验证，如果是固定不变的那就是没有意义的，如果说每个用户对应有一个，就像密码一样的东西那就是有意义的

也未必没有意义啊，可以在用户第一次访问时候生成一个随机字符串，放入cookie，以后的请求都从cookie里面去字符串来验证用户，我觉得这样的方案也可以啊。
有点类似auth2的验证方式

使用https、js压缩，这应该是最便捷有效的方法了吧

你可以了解一下token验证，现成的解决方案:jwt

确实没有意义，api和普通的页面展示没什么区别，无非就是普通的页面混合了标签，更难采集罢了，想限制一些功能，就通过会员类似的功能来限制，不重要的内容本来就是放在公网让人访问的，普通页面不限制，api同样不用限制。
网页浏览的webapi和给app提供的api还是有区别的，app由于加固等措施可以存储敏感信息，所以可以加token等能防止普通的接口也不会被轻易访问，而js是完全透明的，所以无法做到同app似的限制普通的接口。

你这个方案是个不算方案的方案。。哈哈
因为你的这个方案的适用范围是互联网原始社会时期的一个“验签”方式。
随着前端程序猿的增多，他肯定知道这样能看 js 代码，进而能知道你们的秘密。
当这个秘密不再是秘密的时候，web 安全就会进入下一个阶段，给你们的字符串进行加密，然后再传给后端进行校验。
攻防总是相辅相成互相进步的，然后 web 安全就又进入下一阶段，等等等等。
cookie session md5 des rsa token oauth ssl cert 都是一步步发展过来的。
所以说 你这个方案的本质是可行的 只是方式是最原始的

没看明白你的意思

刚入手PHP,来学习下

求解????