创建一套可通过Web进行访问的应用程序编程接口并不困难，但打造一套既运作良好又稳定可靠的API却没那么容易，Stormpath公司首席技术官Les Hazlewood在JavaOne 2013大会上表示。为了顺应与会观众们的强烈呼声，Hazlewood于本周二重返JavaOne舞台、向大家介绍了如何利用JAX-RS与Jersey创建优秀的REST + JSON API。 “一款出色的具象状态传输（简称REST）API从表面上看应该很简单，即使其后端机制实际相当复杂，”Hazlewood在介绍环节之前的记者采访中指出。如果一款API的专注重点在于收集信息并为各条信息提供各自独立的代表，那么只要削减API中的收集及搜索机制（而非罗列所有已经采用的对象），我们就能获得一款简洁而出色的方案，直观而绝不复杂。
Les Hazlewood 在问答环节中，Hazlewood深入探讨了API最佳实践、REST API的优势与劣势以及JavaScript Object Natation（简称JSON）等话题。 为什么Java开发人员乐于尝试REST API？ Les Hazlewood: REST是一套以现有HTTP为基础建立起来的架构风格。在HTTP规范当中，我们交换数据以及创建、读取、更新与删除数据的方式已经被确定下来。在互不相干的设备中创建即读即删信息时，REST能够负责决定特定情况该如何处理。 这正是REST的主要作用；负责此类操作在互不相干的设备间执行时该如何处理。由于REST以HTTP为基础，因此我们可以在Linux设备、Windows设备与苹果Mac设备之间进行通信。总之，REST无需局限于特定平台或者供应商类型——由于HTTP无处不在，因此REST也能够广泛起效。所有编程语言，包括Python、PHP、Java以及C#，都能够与REST并行协作。 从各个方面来说，REST往往由于自身的迷惑性而被看得过于简单。每个人都自认为了解HTTP，因为这正是Web浏览器的表面方式。技术人员了解HTTP协议、GIT以及POST，因为他们已经以Web形式与之接触多年。而由于REST使用HTTP协议，开发人员会习惯性地低估其实际复杂性。事实上，如今的REST服务已经远远超过XML（过去一直搭配SOAP，即简单对象访问协议）的范畴。 使用REST会遇上哪些难点？ Hazlewood:这正是我来到这里向大家进行介绍的原因。REST是一种架构风格，但其使用方法还缺乏正式的标准或者规范。要了解这种风格，我们需要为其添加注释，否则不同使用者对于功能的理解与效果会出现一定程度的偏差。这是因为REST并非一套能够在设备之间直接照搬的规范，而且人为因素的介入也会引发歧义。在这样的情况下，要正确或者轻松使用REST将变得充满困难。REST与JSON都很简单，HTTP也很简单，但在将这几种机制结合起以解决特定问题时，大家会发现自己很难找到既定的成熟指导。 您在JavaOne介绍环节中建议将JSON与REST相结合，还有其它什么理由吗？ Hazlewood: REST与JSON提供了更为人性化的数据表示方式；数据看起来不再像XML格式那样拥挤；更便于我们直接用肉眼查看。而这正是JSON被广泛采用的真正原因。 JSON是一种语法规则。简单概括，它的内容就是字符串、数字、空、非空。它允许大家以非常简单的格式通过少量元数据表示复杂的情况。我们能够轻松将其使用在多种不同环境之下。它易于机器解析，也同样适合人们直接阅读。 JavaScript是目前世界上最具影响力的重要编程语言之一。即使是在主要由Java、Python或者C#编写的应用程序中，一旦涉及网页或者直观用户界面，那么出场解围的也必然是JavaScript。JSON与JavaScript完全兼容，任何拥有JavaScript编程经验的技术人员都能轻松掌握JSON。如果大家已经跟JavaScript打过交道，那么将其与API相整合也绝非难事。如果API返回JSON且大家已经利用JavaScript编写代码，那么编程语言本身就会了解如何阐释来自服务器的数据。JSON借助人气极盛的JavaScript处理数据交换（而不仅是写入软件）任务。 何时适合使用JSON，何时不适合？ Hazlewood:很显然，XML在数据复制架构方面的表现更出色。XML文档中包含的信息更丰富，而且其中的数据类型划分也更为高效。XML非常适合处理数据交换任务，但糟糕的易用性往往令开发人员望而却步。JSON内容适合直接阅读，XML在设计方面则更为复杂。JSON的语法简单易懂。说起语言设计，JSON中的核心元素非常有限，全部开发成果都以此为基础。由于其出色的简单特性，我们能够轻松对其加以操控及理解。不过在设备消耗信息方面，JSON的表现远不如XML。XML更适合设备直接处理。 |
