mayne95 最近的时间轴更新 mayne95 最近的时间轴更新 |
mayne95V2EX 第 173562 号会员，加入于 2016-05-18 10:52:36 +08:00今日活跃度排名 10469 |
https://gine.me
深圳
mayne95 最近回复了
7 天前 回复了 Archeb 创建的主题 › GitHub › 用伊朗 IP 访问了下 GitHub，账号被 restricted 了，有救吗 |
看完全文再看楼主头像，莫名喜感 哈哈哈
11 天前 回复了 renmu123 创建的主题 › 分享创造 › 零基础新手这几天在学板绘，练了几天线稿之后不知道下一步应该干什么了？求大佬指教 |
书：《素描的诀窍》
Up 主： https://www.youtube.com/channel/UClM2LuQ1q5WEc23462tQzBg
网站： https://line-of-action.com/practice-tools/
加油！共勉！
Up 主： https://www.youtube.com/channel/UClM2LuQ1q5WEc23462tQzBg
网站： https://line-of-action.com/practice-tools/
加油！共勉！
17 天前 回复了 findsomeone 创建的主题 › 分享发现 › 坚果 pro3 实在让我失望，宣传上的听觉无障碍模式压根没有适配 |
锤子出发点是好的，就是虚假宣传有点恶心。明年母公司技术下放到子公司，苹果就会给这个功能安排上了。
75 天前 回复了 melkor 创建的主题 › Android › Android 10 更新后无法设置声音、无法截图 |
beta 测试的时候就有这样的问题，看起来还是没解决。可以尝试这重新给 app 权限（应用管理里面，先关闭权限再打开）
万能方案：重启试试
万能方案：重启试试
75 天前 回复了 ericgui 创建的主题 › Node.js › Headless CMS + React |
再用上 Netlify、Cloudflare-worker 这些服务。JAMstack、FaaS 一把梭是真的很舒服。
83 天前 回复了 ikaiguang 创建的主题 › 服务器 › 如何看待：不遵循 restful_api 设计，所有的 api 使用 POST 提交 |
谢邀(并没有)
既然楼主用知乎的提问体，那么我就用知乎的回答体。
抛开业务场景谈 API 设计的都是耍流氓（加粗）
规则是个约定俗称的东西，能减少沟通成本，但规则本身也有学习成本。如果 rest 是有 RFC 支持，白纸黑字明文规定的规则。那非常好，大家都按这个来，不会出什么幺蛾子。V 站也不会有人隔三差五的出来讨论 rest 规范。
(不管对不对，先踩一番显得自己很高明的亚子）
像 REST 这种含糊不清的约定本来就是一坨 shit，restful ful ful 风格你懂吗，你的 API 有自己的 freestyle 嘛？真是滑天下之大稽！正如 5 楼所说，rest 不是标准，不是标准，不是标准。API 能在符合 HTTP 协议的情况下运行起来即可。
这个问题就像是，你觉得空格好还是 tab 好。又比如函数式之于面向对象。如果今后 graphql 普及，这个问题还有意义嘛？
拿前朝的剑斩本朝的官？（大雾）
在那个 API 风格混乱的年代，rest 的出现如同指路明灯。大家都按着这个来，减少了混乱，降低了沟通成本。这是值得肯定的。但是随着业务场景逐渐复杂，API 的设计已经没法完全符合 rest 的理念了。花心思去设计一个看起来美好的格式高度统一的 API，不如直接加个接口来的简单。
全用 post 是有缺陷的。举个例子，如果前端要上 service worker，这时候 API 全用 post，请求是没法被拦截并缓存的，也就谈不上什么离线应用。这种场景下用 rest 是保险的。
GitHub 的 API 堪称业界典范，程序员都喜欢。notion 获取数据全用的 post 请求，但这并不妨碍我喜欢它。重要的是产品。
好的 API 是自描述的，能够自洽的，符合直觉的。用户在使用某个接口后，能够推导出其它接口的用法。API 面向的用户群体是程序员，对于程序员来说文档最重要。文档是最好的约定，rest 不 rest 无所谓啦。
既然楼主用知乎的提问体，那么我就用知乎的回答体。
抛开业务场景谈 API 设计的都是耍流氓（加粗）
规则是个约定俗称的东西，能减少沟通成本，但规则本身也有学习成本。如果 rest 是有 RFC 支持，白纸黑字明文规定的规则。那非常好，大家都按这个来，不会出什么幺蛾子。V 站也不会有人隔三差五的出来讨论 rest 规范。
(不管对不对，先踩一番显得自己很高明的亚子）
像 REST 这种含糊不清的约定本来就是一坨 shit，restful ful ful 风格你懂吗，你的 API 有自己的 freestyle 嘛？真是滑天下之大稽！正如 5 楼所说，rest 不是标准，不是标准，不是标准。API 能在符合 HTTP 协议的情况下运行起来即可。
这个问题就像是，你觉得空格好还是 tab 好。又比如函数式之于面向对象。如果今后 graphql 普及，这个问题还有意义嘛？
拿前朝的剑斩本朝的官？（大雾）
在那个 API 风格混乱的年代，rest 的出现如同指路明灯。大家都按着这个来，减少了混乱，降低了沟通成本。这是值得肯定的。但是随着业务场景逐渐复杂，API 的设计已经没法完全符合 rest 的理念了。花心思去设计一个看起来美好的格式高度统一的 API，不如直接加个接口来的简单。
全用 post 是有缺陷的。举个例子，如果前端要上 service worker，这时候 API 全用 post，请求是没法被拦截并缓存的，也就谈不上什么离线应用。这种场景下用 rest 是保险的。
GitHub 的 API 堪称业界典范，程序员都喜欢。notion 获取数据全用的 post 请求，但这并不妨碍我喜欢它。重要的是产品。
好的 API 是自描述的，能够自洽的，符合直觉的。用户在使用某个接口后，能够推导出其它接口的用法。API 面向的用户群体是程序员，对于程序员来说文档最重要。文档是最好的约定，rest 不 rest 无所谓啦。
86 天前 回复了 mayne95 创建的主题 › 分享创造 › 🎧 写了个 PWA 播放器解决个人听歌难的问题 |
@Aether 服务跟硬件绑一起了......
87 天前 回复了 mayne95 创建的主题 › 分享创造 › 🎧 写了个 PWA 播放器解决个人听歌难的问题 |
@sobigfish
我在造轮子之前想过这些问题，具体解释下如何处理版权问题。
1. 不是所有的音乐都存在版权问题（演示用的音乐存在问题，我偷懒了）
2. 如果没有分享意图，可以把数据设置为私密，个人使用是没有问题的。你可以理解为 PWA 就是个离线应用，跟普通的本地音乐软件没有区别。notion 相当于网易云音乐云盘。
3. 如果有分享意图，可以分享没有版权问题的内容，或者上传自己创作的内容（播客、ASMR、个人作曲等）。
4. 以上做法没有违反 notion 的 tos
我在造轮子之前想过这些问题，具体解释下如何处理版权问题。
1. 不是所有的音乐都存在版权问题（演示用的音乐存在问题，我偷懒了）
2. 如果没有分享意图，可以把数据设置为私密，个人使用是没有问题的。你可以理解为 PWA 就是个离线应用，跟普通的本地音乐软件没有区别。notion 相当于网易云音乐云盘。
3. 如果有分享意图，可以分享没有版权问题的内容，或者上传自己创作的内容（播客、ASMR、个人作曲等）。
4. 以上做法没有违反 notion 的 tos
89 天前 回复了 mayne95 创建的主题 › 分享创造 › 🎧 写了个 PWA 播放器解决个人听歌难的问题 |
@devtiange https://github.com/mayneyao/Notabase/blob/master/src/cf-worker.js
Google 家的产品线太乱了，又是 Google music 又是 YouTube music。不知道怎么玩，体验没 Spotify 舒服
Google 家的产品线太乱了，又是 Google music 又是 YouTube music。不知道怎么玩，体验没 Spotify 舒服
Select Language