在目前的文档中，提到有几种 handlers，包括通用的 onRequest() 和指定 HTTP 方法的，如 onRequestGet()，但没有提及过它们的优先级，即同时存在时，会优先被哪个处理。
在大半年前，我曾测试过实际行为——特定方法的优先级会比通用的 onRequest() 高，于是写出了这样的代码：
export async function onRequestPost(context) {
// 略：业务逻辑
}
/**
* 兜底处理 - 返回 405 Method Not Allowed
*/
export async function onRequest() {
return new Response(JSON.stringify({
success: false,
message: 'Method Not Allowed'
}), {
status: 405,
headers: {
'Content-Type': 'application/json',
'Allow': ['POST'],
}
});
}
这么写是因为，如果没有兜底，使用不支持的方法会报错 400，而不是 405，不便于排查。
但大约在这几天，我发现服务大面积失效了，排查后定位到了问题在于当前 onRequest() 的优先级比 onRequestPost() 更高了，于是所有对应的 API 都会返回 405。当然，我自己也有问题，利用了文档中未定义的行为。
现在，我对此问题提出两个建议：
- 建议在文档中明确优先级，且建议定义特定处理器的优先级高于通用处理器。
- 建议增加一个配置项，允许一个接口只定义了部分方法的处理器时，用不支持的方法会返回 405，以支持 RESTful。
在目前的文档中，提到有几种 handlers，包括通用的
onRequest()和指定 HTTP 方法的，如onRequestGet()，但没有提及过它们的优先级，即同时存在时，会优先被哪个处理。在大半年前，我曾测试过实际行为——特定方法的优先级会比通用的 onRequest() 高，于是写出了这样的代码：
但大约在这几天，我发现服务大面积失效了，排查后定位到了问题在于当前
onRequest()的优先级比onRequestPost()更高了，于是所有对应的 API 都会返回 405。当然，我自己也有问题，利用了文档中未定义的行为。现在，我对此问题提出两个建议：