产品
曾经写过Jira API的踩坑记、一起吐槽接口文档两篇文章吐槽Jira API接入过程中遇到的抗，原以为Jira API的坑已经踩得七七八八所剩无几了。没想到最近一次功能改动又让我见识到了Jira API的混乱。
背景是我们需要实现更多Jira API功能的封装，使自动化的缺陷的管理、缺陷的统计、缺陷通知更加精细，所以又看了几个Jira API的接口文档。然后呢？我又要吐血了。
由于使用了Jira的新版本，所以之前的接口文档已经失效了（谨慎而言），但是经过一遍尝试之后发现之前的实现方式原来都可以正常使用，看来Jira API在兼容旧版本方面做的真是好。只需要实现几个新功能的API即可完成这个工作目标。
可我还是太天真了，Jira API怎会给我一条康庄大道。
下面是我在处理Jira显示缺陷状态这个数据的时候用到的六种传参方式，其中有获取有设置，而且相互之间不兼容，最可恶的还是不同的接口使用的某一个状态的name还是不一样的，比如关闭状态，在搜索功能用的name是Closed，然后在统计的时候用的是关闭。所以Jira API一般GET接口会返回很多信息，如果各位不幸遇到，请多关注那些自己暂时用不到的信息，很可能它就是解开另外一个接口上传参数的钥匙。
正常来说，针对某一个状态，我们会对应是个文字描述（一般只有前端显示用），在Jira API中通常使用name来表示，然后后端数据库层面，通常使用一个整数型的数据记录，通常使用id，为了统一接口设计字段规范，一般使用id进行数据传输（请求和返回），然后前端将id转成name显示，可以通过接口获取缓存或者写到前端代码中。
Jira API已经证实不按套路出牌，下面是我遇到的关于缺陷状态字段相关功能六种传参方式，各位自行理解：
155-2731-8020
