论文总字数：31359字

摘 要

在信息化高速发展的今天通过计算机技术来改善人们的日常生活是计算机技术发展的重要因素，在10年前人们出行只能依靠绘制的纸质地图，而现在可以很方便的通过手机，平板，电脑中的电子地图进行导航。电子导航在这几年中经历了很大的改进与发展，如今市场上成熟的地图应用有谷歌地图，高德地图，百度地图等等，基本能够满足人们的日常使用。

电子地图要能够方便使用，需要背后一个庞大的数据库作为支撑，在已经存在庞大地图数据的前提下，如何高效的获取这些数据已经成为提高电子导航效率的关键因素之一。

这篇论文出发点即如何简洁高效获取这些已经存在的海量数据，来在电子地图上显示信息，供使用者进行导航。当下在电子地图上获取数据的web service方式大多数采用的是SOAP（简单对象访问协议），这个协议最大的问题在调用方式复杂，有违了HTTP协议简洁明了的初衷。我通过使用REST 风格的webservice设计原则来取代SOAP方式，使数据获取方式更简洁，清晰与易懂，从而提高软件开发的效率以及数据获取效率。论文通过Android APP 导航应用的方式来展现结果。

关键词：android，交通，导航， REST，SOPA，web services，App

The design of Android Area Navigation System

Abstract

The rapid development of information technology in today's computer technology to improve people's daily lives is an important factor in the development of computer technology, 10 years ago to draw people to travel to rely on paper maps, but now you can easily through the phone, tablet, computer electronic map navigation. Electronic navigation in these years has experienced great improvement and development, the mature market now has a Google Maps map application, high moral map, Baidu map, etc., can basically meet people's daily use.

To be able to facilitate the use of electronic maps, you need a huge database behind as a support, in the presence of a huge map data has been the premise of how to efficiently access these data has become a key factor in improving the efficiency of electronic navigation.

That is the starting point of this paper how to efficiently get these huge amounts of data that already exists, to display the information on the electronic map for users to navigate. Moment to get data on the electronic map web service methods most used is SOAP (Simple Object Access Protocol), the protocol calls the biggest problem in a complex way, contrary to the original intention of the HTTP protocol concise. I'm using the REST-style design principles to replace the SOAP webservice ways to make the data acquisition method is more concise, clear and easy to understand, thereby enhancing the efficiency of software development and data acquisition efficiency. To show results by way of Android APP navigation applications.

Key words：android，Traffic，Navigation，REST，SOPA，web services，App.

目 录

摘要 i

目 录 II

第一章 引言 1

1.1 REST的提出 1

1.1.1 HTTP1.1 1

1.1.2 REST 1

1.2 REST的兴起 2

1.3 REST的优点 2

1.4 REST与SOPA的比较 3

1.5 Android区域导航系统框架结构 3

第二章 REST基础 4

2.1什么是REST 4

2.1.1 定义 4

2.2 REST设计原则 4

2.2.1可寻址性 4

2.2.2无状态性 5

2.2.3统一接口 5

2.2.4资源表示 6

2.2.5 超媒体作为应用状态引擎 6

2.3 设计REST API 7

2.3.1 资源设计 7

2.3.2 规划数据集 7

2.3.3 把数据集划分为资源 8

2.3.4 命名资源 8

2.3.5 设计表示 9

2.3.6 把资源相互连接起来 9

2.3.7 HTTP响应 9

第三章 百度地图Android API基础 12

3.1 百度地图Android API 12

3.2 百度地图Android API key申请 12

3.3百度地图Android 常用API简单介绍 13

3.3.1地图图层 13

3.3.2检索服务 14

3.3.3路径规划 15

3.3.4覆盖物 16

3.3.5定位 16

第四章 服务器端实现 17

4.1 场景 17

4.2选择实现的工具 17

4.2.1 为什么选择Java语言 17

4.2.2 XML与JSON的比较 18

4.2.3 Rails，Restlet，Django的比较 18

4.3需求分析 20

4.4 数据库设计 23

4.5 MVC 模型 25

4.6 REST风格在服务器端的体现 27

4.6.1可寻址性体现 27

4.6.2无状态性体现 28

4.6.3统一接口体现 28

4.6.4资源表示体现 28

4.6.5超媒体作为应用状态引擎体现 29

第五章 客户端的实现 30

5.1需求分析 30

5.2 XML解析器的设计 31

5.2.1 XML解析器接口类的设计 32

5.2.2 XML解析器具体类ShopTableXmlParser的实现 33

5.3 model层类的设计 34

5.4搜索功能的设计 34

5.4.1 客户端发出请求 34

5.4.2 客户端接受数据 35

5.4.3 客户端呈现数据 35

5.4.4 地图上显示目标 36

5.5定位功能与导航的实现 36

5.5.1 定位到用户当先位置 36

5.5.2 绘制导航路线 38

第六章 系统测试 41

6.1 测试的基本概念 41

6.1.1 测试方式 41

6.2 测试方案 41

6.2.1 测试计划 41

6.2.2 测试用例设计 42

6.3 测试结果 42

第七章 总结 43

7.1服务器端 43

7.1.1 经验教训 43

7.1.2 将来的改进之处 44

7.2客户端 44

7.2.1 经验教训 44

7.2.2 将来的改进之处 44

第一章 引言

1.1 REST的提出

REST 一词的出于Roy Fielding的博士论文《Architectural Styles and the Design of Network-based Software Architectures》，从标题来看，它是一种架构样式 (Architectural Styles) 与软件架构 (Software Architectures)。REST是随着HTTP协议规范一起提出的。

1.1.1 HTTP1.1

HTTP 是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的发展使用，得到迅速地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行当中，而且HTTP-NG的建议已经提出。  HTTP协议的主要特点可概括如下：  1.支持客户/服务器模式。  2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。  3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。  4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。 

1.1.2 REST

REST ( REpresentational State Transfer )，State Transfer 为 "状态传输" 或 "状态转移 "，Representational 中文翻译为"表征"、"具象"，合起来就是 "表征状态传输" 或 "具象状态传输" 或 "表述性状态转移"，不过，一般文章或技术文件都比较不会使用翻译后的中文来撰写，而是直接引用 REST 或 RESTful 来代表，因为 REST 一整个观念，想要只用六个中文字来完整表达真有难度。

REST是以网络 (Network-based) 为基础，重点就是：

1.架构样式 (Architectural Styles)

2.软件架构 (Software Architectures)

3.网络 (Network-based) 为基础

4.REST 本身是设计风格而不是标准。

1.2 REST的兴起

在过去几年的公司，如谷歌，Twitter的，亚马逊和Facebook已经开始 改变我们日常生活的许多方面。我们用它们与所有类型的设备：电脑， 手机和平板电脑。他们还嵌入在我们使用许多其他产品。 其中之一 。他们都提供了数量巨大的API来为开发者在不同的设备和网络提供服务。为了满足数以百万计的API 每分钟的请求这些公司不得不想出一个有效的架构。而其中绝大部分使用的就是REST架构风格。

1.3 REST的优点

REST简单而直观，把HTTP协议利用到了极限，在这种思想指导下，它甚至用HTTP请求的头信息来指明资源的表示形式（如果一个资源有多种形式的话，例如人类友善的页面还是机器可读的数据？），用HTTP的错误机制来返回访问资源的错误。由此带来的直接好处是构建的成本减少了，例如用URI定位每一个资源可以利用通用成熟的技术，而不用再在服务器端开发一套资源访问机制。又如只需简单配置服务器就能规定资源的访问权限，例如通过禁止非GET访问把资源设成只读。

服务器无状态带来了更多额外好处，因为每次请求都包含响应需要的所有信息，所有状态信息都存储在客户端，服务器的内存从庞大的状态信息中解放出来。而且现在即使一台服务器突然死机对客户的影响也微乎其微，因为另一台服务器可以马上代替它的位置，而不需要考虑恢复状态信息。更多的缓存也变成可能，而之前由于服务器有状态，对同一个URI的请求可能导致完全不同的响应。

1.4 REST与SOPA的比较

SOAP (Simple Object Access Protocol) 顾名思义，是一个严格定义的信息交换协议，用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。事实上SOAP数据使用XML数据格式，定义了一整套复杂的标签，以描述调用的远程过程、参数、返回值和出错信息等等。而且随着需要的增长，又不得增加协议以支持安全性，这使SOAP变得异常庞大，背离了简单的初衷。REST的请求和应答数据简单可读，而SOAP则需要一系列繁琐的封装；即使如此，SOAP仍然不能达到接口的一致性，不同的厂商有各自的接口，而REST只使用HTTP定义的方法，因此是通用的。

1.5 Android区域导航系统框架结构

Android区域导航系统前后一共分成服务器端和前端（客户端）以及数据库端，服务器端是在J2EE的平台上开发完成的，而前端（客户端）使用的是Android开发平台，以手机App的形式发布，数据库端使用的是MySQL数据库，数据库持久层使用的是流行的Hibernate框架。

第二章 REST基础

2.1什么是REST

术语REST是由Roy Fielding在介绍他2000的博士论文在中提出的，在论文他谈到络在一般的网架构中定义REST。

2.1.1 定义

REST ( REpresentational State Transfer )，State Transfer 为 "状态传输" 或 "状态转移 "，Representational 中文翻译为"表征"、"具象"，合起来就是 "表征状态传输" 或 "具象状态传输" 或 "表述性状态转移" 。

2.2 REST设计原则

REST并不是一种架构，而是一组设计原则，你可以将“在遵守这些原则方面，一个架构比另一个架构好”，但是你不能讲“REST架构”，因为不存在一个叫做“REST架构的东西”。

2.2.1可寻址性

如果一个应用将其数据集里面的有价值的部分作为资源（resources）发布出来，那么该应用就是可寻址的。因为资源是通过URI暴露的，所以一个可寻址的应用会为它可能提供的每一则信息都发布一个URI。一般来书，URI的数量是无限的。一个URI可以作为另一个URI的输入。可寻址性是Web应用的最大优点，它令客户端可以灵活自由地使用网站，甚至可能创造出超出网站设计者想象的使用方式。

Web应该是可寻址的，但许多的Web应用确实不可寻址的尤其是Ajax应用。

2.2.2无状态性

无状态性是REST的另一个主要特征。无状态性意味着每个HTTP请求都是完全孤立的，当客户端发出一个HTTP请求时，请求里面包含服务器实现该请求所需的全部信息，服务器不依赖任何之前提供的请求提供的信息。假设本次请求需要之前某个请求提供的信息，那么客户端应当把那个信息也包括在本次请求里。

虽然REST包含无状态性的观念，但这并不是说暴露功能的应用不能有状态，事实上，在大部分情况下这会导致整个做法没有任何用处。REST要求状态要么被放入资源状态中，要么保存在客户端上。或者换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的通信状态。这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的内存可用空间。

但除此以外，其它方面可能显得更为重要：无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器。一个客户端从某台服务器上收到一份包含链接的文档，当它要做一些处理时，这台服务器宕掉了，可能是硬盘坏掉而被拿去修理，可能是软件需要升级重启——如果这个客户端访问了从这台服务器接收的链接，它不会察觉到后台的服务器已经改变了。

2.2.3统一接口

REST 架构风格的核心特征就是强调组件之间有一个统一的接口，这表现在REST世界里，网络上所有的事物都被抽象为资源，而REST就是通过通用的链接器接口对 资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况 做了优化，使得REST接口被设计为可以高效的转移大粒度的超媒体数据，这也就导致了REST接口对其它的架构并不是最优的。

1.GET

HTTP的GET方法描述了关于资源的信息的请求。发送一个GET请求，服务器将用报头和含有表示的报文实体部分响应所请求的资源。

2.PUT

HTTP的PUT方法，客户端可以通过发送一个PUT请求来创建或者修改一个资源。该PUT请求通常包含一个实体主体，其中是客户端为该资源提供的新的表示。这个表示具体包含什么数据，采用什么格式等，因具体服务而异。但无论如何，应用状态由此转移到了服务器上，成为资源状态。

3.POST

POST的目的是允许采用一个统一的方法来作以下操作：对现有资源进行注释；向公告板，新闻组，邮件列表等发布一则消息；向一个数据加工处理程序提供一个数据块；通过一个添加操作来扩充数据库。

POST方法实际执行的操作由服务器决定，而且一般要根据所请求URI。被POST的实体从属于那个URI，就如同一个文件从属于包含它的目录，一片文章从属于它被发布的新闻组，以及一条记录从属于某个数据库一样。

4.DELETE

DELETE方法用来删除已经存在的资源。

2.2.4资源表示

资源表示描述以什么格式的数据在服务器与到客户之间进行交换。常见的有XML，JSON，HTML。但是因为没有有严格的区别，所以资源和它的表示之间可以被转换为其它任何表示。这是为什么说REST架构是松散耦合的一个原因。它表示还可以处理语言的内容。一般说来，面向资源的体系结构从服务器给客户端 发送数据格式，正是客户端所要求的格式。

2.2.5 超媒体作为应用状态引擎

“将超媒体作为应用状态的引擎” （Hypermedia As The Engine Of Application State）又名“超文本驱动”，来自Fielding博士论文中的一句话，缩写为HATEOAS。将Web应用看作是一个由很多状态（应用状态）组成的有限状态机。资源之间通过超链接相互关联，超链接既代表资源之间的关系，也代表可执行的状态迁移。

在超媒体之中不仅仅包含数据，还包含了状态迁移的语义。以超媒体作为引擎，驱动Web应用的状态迁移。通过超媒体暴露出服务器所提供的资源，服务器提供了哪些资源是在运行时通过解析超媒体发现的，而不是事先定义的。从面向

服务的角度看，超媒体定义了服务器所提供服务的协议。

客户端应该依赖的是超媒体的状态迁移语义，而不应该对于是否存在某个URI或URI的某种特殊构造方式作出假设。一切都有可能变化，只有超媒体的状态迁移语义能够长期保持稳定。

2.3 设计REST API

由于 REST 可以降低开发的复杂度，提高系统的可伸缩性，增强系统的可扩展性，简化应用系统之间的集成，因而得到了广大开发人员的喜爱，同时得到了业界广泛的支持。比如 IBM，Google 等公司的很多产品都提供了 REST API 给开发人员；与此同时，大量的开源项目和云计算服务都提供了 REST API 接口。

而在最近，一些新产品的开发甚至已经几乎完全抛弃了传统的类似 JSP 的技术， 转而大量使用 REST 风格的构架设计， 即在服务器端所有商业逻辑都以 REST API 的方式暴露给客户端， 所有浏览器用户界面使用 widget，Ajax，HTML5 等技术，用 HTTP 的方式与后台直接交互。我们应该如何更好的设计我们的接口， 来提高我们的 API 的可用性，易用性，可维护性与可扩展性。

2.3.1 资源设计

面向对象程序的标准设计方法是把系统分解为一个个功能部件，即其中的名词。一个对象是某个事物。每个名词都有自己的类和自己的方法。一个资源是某个事物。其实可以把面向资源的设计策略称为“极限面向对象的”策略。

编程语言里的个类可以暴露无数个方法，并给这些方法取任意名称。但是，一个资源只暴露一个统一接口，最多支持六种Hl7P方法，这些方法只允许创建(PUT或POST)、修改(PUT)、读取(GET)和删除(DEIETE)这些最基本

的操作。如果需要，你也可以通过重载(overload) POST来扩展该接口，把一个资源变成一个小型RPC式消息处理器。

2.3.2 规划数据集

设计一个Web服务，首先要有一个数据集(data set)或至少是关于一个数据集的设想。该数据集是你将要暴露的，而且，或者要让你的用户构建的。无论采用什么设计方法，这总是第一步要做的。有时候你要选择数据集，有时试图暴露已经有的数据。才发现把数据暴露为资源的好处之后，才会回到这一步。比如：在面向资源的分析里，查找数据这个操作本身就是数据。假如你把一个算法的输出看作一个资源的话，那么要执行该算法，就只要想该资源发送GET请求就行了。

2.3.3 把数据集划分为资源

一旦你规划好数据集后，下一步要决定的，就是如何把数据作为HTFP资源束发布。记住，一个资源就是任何值得作为超链接目标的事物。任何可能用名称来引用的事物都应该有白己的名称。服务暴露的资源可分为三类。

1. 为特别目的专门预定义的一次性资源。 这包括其他可用资源的最上层日录。大多数服务几乎不暴露一次性资源。
2. 服务暴露的每一个对象所对应的资源。一个服务可以暴露很多对象，每一种都有自己的资源集合。大多数服务暴露很多（甚至无数）个这样的资源。
3. 代表在数据集上执行算法的结果的资源。这包括作为杏询结果的集合资源。对于大多数服务，此类资源不是有无数个，就是一个也没有。

REST式Web服务通过资源来暴露数据和算法。有关数据的资源常常构成一个层次结构( hierarchy)：由很少的资源开始，然后逐渐扩展为具有许多叶结点。要理解“把算法暴露为资源”这一方式，是需要一些时间的。你不要从动作方面来考虑，而要从该动作的结果方面来考虑。当发现你的设计不符合HTTP统一接口时，需要冉回到这个步骤。

2.3.4 命名资源

在确定好各种资源之后就要给这些资源命名。因为资源是以URI命名的，所以给资源命名就相当于给资源设计URI。设计的资源名称，其URI应包含所有的作用域信息。

URI设计有三类基本原则：

请支付后下载全文，论文总字数：31359字