想知道获取节假日API制作流程是什么吗?

　　一套成熟的获取节假日API，很多时候都是不断演化迭代出来的，很少有API的设计和实现从最开始就是完美无瑕疵的。首先，做过API的人都知道，一个上线使用的API再想改它的signature，通常由于compatibility的原因，后期再想改，都是格外痛苦不堪的。因此，API signature设计初期，一定要反复推敲再推敲，尽量避免上线后的改动。

　　而除了一些基本的RESTful原则外，Signature的定义很多时候是对业务逻辑的抽象过程。一个系统的业务逻辑可能错综复杂，因此API设计的时候就应该做到用最简洁直观的格式去支持所有的需求。这其实往往是API设计中相对立的两面。有时候我们为了支持某一个功能，似乎不得不增加一个很违反设计的接口;而有时候我们为了保证API绝对规范，似乎又不得不放弃对某一些功能的直接支持，因此功能只能通过迭代调用或client端预处理来实现。

　　而这种设计上的取舍，通常只有列出所有可行的方案，从简单的设计到繁杂的设计，然后通过分析各种使用实例的频率和使用某种设计时的复杂度，从实际的系统需求入手，尽可能让常用的功能得到最简单直接的支持，而一定程度上“牺牲”一些极少用到的功能。反复推敲系统场景，尽可能取得一个合理的折衷。

　　写软件也是一样。一个小startup里，API怎么设计，代码怎么写，几个人一协商，达成共识，并不需要那么多的条条框框，也照样行的通。公司一大，代码协作的人越多，每个人的自由就会导致最终的冲突甚至问题。所以，很多大公司会制定一些API的best practice，强制要求设计和实现中必须按照某种模式来做。有些规则虽有道理，但也不是说不这样不行。

　　很多时候，就因为这样的原因，我们的获取节假日API设计中会有很多限制，表面上似乎给设计带来无谓的难度，但是仔细考量，从规范代码一致性的角度而言，还是有很大好处的。

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com