Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
具体说下
在保持APIJSON现有功能的情况下，建议：
APIJSON能够改造成开发过程中替代Mock和API管理的一个接口开发利器，具体流程如下
1、后端建好库，自动化生成APIJSON项目，可供前端调用
2、前后端商量好接口，前后端分别进入开发
3、前端遇到后端没有开发完成的接口，直接使用APIJSON进行开发调试（需要设计普通API接口和APIJSON的调用转换器，APIJSON界面上对进行调用的接口要进行标示）
4、前端调试完成后，接口固定下来，由后端接手进行实现
5、APIJSON能够与API接口管理工具如（YAPI）进行接口数据同步
6、APIJSON能够对后台开发的接口进行自动化测试
7、后端人员写完所有接口及测试完成后，APIJSON圆满完成任务，迭代新增功能时可以继续这个流程。
为什么
1、除开个人开发者，团队开发的话，接口完全使用APIJSON对团队来说顾虑比较多，部分使用的话又感觉不好维护。
2、前后端分离团队开发目前使用Mock和API管理的方案其实并不完美，有很多情况Mock不好解决，远远不如直接连接数据库进行开发。
3、前端人员了解一定的数据库知识，开发期间自行修改字段，调整JSON结构，符合前端需要，在频繁调整业务界面期间不需后端人员参与，这样才能真正提升团队整体开发效率。