如何验证所测试的API是否正常工作

两种做法都不准确，判断标准完全取决于你说的「API正常工作」具体是哪个层面的正常。

只请求baseUrl看200状态码的适用边界 #

这是粒度最粗的探活手段，只能证明三件事：域名能解析通、网络链路没断、API对应的入口服务/网关进程没挂。
这个检测结果的参考价值非常低：很多服务的baseUrl就是个写死的静态欢迎页，哪怕后面业务库全挂、所有业务接口都报500，baseUrl照样能稳稳返回200。正规的服务存活探活一般都不会用baseUrl，而是会单独暴露/health、/ping这类轻量检查端点，用来确认服务进程、核心依赖的状态，这种探活只适合运维做告警、部署后确认服务启动成功的场景，证明不了API能正常提供业务能力。

逐一端点发GET请求看是否返回200的逻辑错误 #

这个做法从根上就不符合HTTP接口的设计规范：

• 不同请求方法本来就有明确语义：用来提交数据的POST端点、删除资源的DELETE端点、更新数据的PUT端点，你发GET请求过去返回405 Method Not Allowed才是符合规范的正常表现，返回200反而说明接口设计有问题
• 大部分业务接口都有鉴权、参数校验逻辑：你不带合法token请求返回401 Unauthorized，传了不符合要求的参数返回400 Bad Request，这些非200响应都是接口正常工作的表现，根本不是故障
• 退一步说，就算你用对了请求方法、带了合法凭证和参数，光看200状态码也没用：不少接口设计会在业务逻辑出错时依然返回200状态码，把错误信息塞在响应体里，比如返回{"code":5003,"msg":"数据库查询超时"}，你光看状态码根本发现不了接口已经不能用了

符合实际需求的验证方式 #

根本没必要走两个极端，根据你的验证目标选方案就行：

• 要是只需要确认服务没宕机：请求服务提供的专门健康检查端点，返回200就足够
• 要是只需要确认自己业务要用到的接口能正常跑：不用测所有端点，只针对你实际会调用的接口，按照文档要求构造合法请求（选对请求方法、带齐鉴权信息、传入合规参数），除了校验状态码符合预期（比如新建资源的POST接口正常应该返回201，不是200），还要校验响应体结构、核心返回值符合约定就可以
• 要是做API上线前的全量回归：需要给每个端点设计覆盖正常、异常场景的测试用例，验证所有返回符合接口文档约定，而不是无脑要求所有请求都返回200

内容的提问来源于stack exchange，提问作者DexlonS