V2EX › dnjat 的所有回复 › 第 5 页 / 共 7 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7

❮

❯

2023-11-17 12:59:21 +08:00

回复了 dnjat 创建的主题 › 程序员 › 如何缩短 dao 层命名,selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList

@securityCoding 是手写,mybatis id 名就是这么长.😅

2023-11-17 12:58:50 +08:00

回复了 dnjat 创建的主题 › 程序员 › 如何缩短 dao 层命名,selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList

@flyqie 苹果味是什么样的😄

2023-11-17 12:58:20 +08:00

回复了 dnjat 创建的主题 › 程序员 › 如何缩短 dao 层命名,selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList

@beneo 要逆出什么来😅

2023-11-17 12:57:39 +08:00

回复了 dnjat 创建的主题 › 程序员 › 如何缩短 dao 层命名,selectAllListIdAndUpdateHashAndStateByTaskIdAndUpdateGroupAndStateList

要逆出什么来😅

2023-10-26 21:35:37 +08:00

回复了 dnjat 创建的主题 › 程序员 › 文本内容审核,短文字收费.

@rekulas 机器学习前期投入太大了,不熟悉的话,学习,调优也是个成本. 不怕他误审,怕他识别不出风险,如果不是很相信自己的学习模型,无风险的,你还是得交三方审核再审一次.

2023-10-26 21:30:56 +08:00

回复了 dnjat 创建的主题 › 程序员 › 文本内容审核,短文字收费.

@luodichen 应该不要吧,审核后有返回命中词,本地再过滤一下就好了.

2023-10-26 21:30:18 +08:00

回复了 dnjat 创建的主题 › 程序员 › 文本内容审核,短文字收费.

@hongfs 有做文件 hash 匹配,但文字的机率应该不合适吧.同样一句话,重新打一遍都有可能会有区别,所以当时就放弃这个缓存方案了. 老兄你的方案是什么样子的.

2023-10-26 18:50:00 +08:00

回复了 dnjat 创建的主题 › 程序员 › 文本内容审核,短文字收费.

@hongfs 这个不好缓存吧，改个标点什么的就不一样了。缓存命中关键字也不行，担心本地缓存的关键字不够。

2023-10-26 18:47:37 +08:00

回复了 dnjat 创建的主题 › 程序员 › 文本内容审核,短文字收费.

@coderxy 是的，主要是成本，不然单条好处理多了，合并后还得拆结果，对不同来源的内容做后续动作，动作还不统一。就看成本与麻烦度的比例怎么样

2023-10-15 08:35:17 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@flyqie 赞同,看场景.

2023-10-15 08:31:46 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@AquanllR rest 是非常简洁,聚合强

2023-10-14 07:09:33 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@YuJianrong 好早啊,莫非在看 ti?😅 一看你就是 graphql 的受益者,当时一看到 graphql 的统一入口就惊呆了,心想这得多麻烦,全放到一个入口路由.不过他的自由查询还是很喜欢的.

2023-10-13 23:00:06 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@impaul put 也是用的 post body 传输方式,delete 用的 url 传值方式.😄 没用过 php,猜想应该也能用$_GET 和$_POST 获取

2023-10-13 22:56:56 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@thinkershare 非常谢谢,我再去深入了解下 rest 起源. 和名字挂边的最麻烦了😄

2023-10-13 22:08:19 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@dddd1919 谢谢指出,短短几句比看几篇博文用处更大. 刚又重翻了一篇 rest 看了下, 更感觉这个 rest 像分了类的 graphql. 如果是复杂的语义,只要对参数下手就行了

2023-10-13 22:01:32 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@zidian 之前都是用的似 rpc 方式,感觉换成 rest,像改变行为习惯一样. 没弄好,是会弄得一团糟.😂

2023-10-13 21:58:18 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@thinkershare 看到的许多博文,大部分都是根据 rest 方式做的分析.所以很想知道这种方式的优势. 如果 api 是面向的还有 app,小程序之类的,也适合 RESTful API 风格吗.

2023-10-13 21:47:43 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@javaisthebest 这个又到了比写代码还花时间的时候了,我应该把他放在哪合适.我应该叫他什么名字.

2023-10-13 21:41:07 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@caisanli /content/create 与/api/content/create 的区分谢谢提醒

2023-10-13 21:39:06 +08:00

回复了 dnjat 创建的主题 › 程序员 › 前后端页面 url 与 api url 如何统一命名风格.

@xiang0818 是的,只是一个路径风格而已,到了服务器都是一样的. 幂等是要注意的,网络是不能相信的😆

1 2 3 4 5 6 7

❮

❯