-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] 提供更加简单化请求方法的修饰器 #18
Comments
@Cyberhan123 可以先提个 RFC 说说自己想要的注解是什么样的。 |
我会在稍后整理出一个PR |
@Cyberhan123 参数是不是可以更简单,比如只有 |
是可以的,我修改了一下。麻烦帮忙review一下看看是不是合理 |
如果默认值都是 |
请教一下,如果按照nest的实现我测试时候是如果请求 @Controller()
class A{
@Get()
function GetA(){
}
@Get()
function GetB(){
}
} 而你的想法是否是:如果没有可选参数,可以通过函数名来匹配; |
HTTP 接口会有不同的风格,比如说 RPC 类型、REST 类型。 可以分两套 api 出来,比如说。 RPC: import { Controller, POST } from '@eggjs/tegg/http/rpc'
@Controller('/api/v1')
class Hello {
// POST /api/v1/helloWorld
@POST()
helloWorld()
} REST: import { Controller, Create, List, Get } from '@eggjs/tegg/http/rest'
@Controller('/api/v1/fruits')
class Fruit {
// POST /api/v1/helloWorld
@Create()
create() {}
@List()
list() {}
@Get()
get(id) {}
} |
个人感觉如果通过包后缀区分不会很清晰,我们是不是应该直接通过Controller区分?就比如普通的Controller,Rest风格的RestController,支持RPC协议的 RPCController,那Rest风格的httpMethod注解应该有哪些估计还需要调研,RPC这里感觉也还有不少问题 |
是的。我们需要一个更完善的 rfc 详细的描述下不同风格的 controller 注解。 |
namespace + controller 可以配合再一起使用。比如说 |
现在的HTTPMethod 虽然足够满足业务需求,但是不够简练,是否能提供 常用的 Get,Post等方法的修饰器
顺带补充,能否提供修改全局route的前缀 ,类似于在配置文件提供
The text was updated successfully, but these errors were encountered: