A. 什么叫NPC,什么叫RPC,什么叫RPG

NPC就是英文（Non Player Character）“非玩家控制角色”的缩写，这个概念最早起源于单机版游戏，逐版渐延伸到整权个游戏领域，举个最简单的例子，您在买卖物品的时候需要点击的那个商人就是NPC，还有做任务时需要对话的人物等等都属于NPC。

对应的一个缩写是PC，即玩家负责控制的登场人物。PC是“玩家控制角色”(Player Character)的缩写。

Remote Procere Call(RPC)是Windows操作系统使用的一种远程过程调用协议

rpg是英文role playing games的缩写。中文意思是角色扮演游戏。一般中文武侠游戏，欧美的龙与地下城规则的游戏都属于这一类。

B. 如何在SOAP协议中设置参数风格 详细

对于使用 ASP.NET 创建的 XML Web services 和它们的使用 SOAP 与 XML Web services 方法进行通讯的客户端来说，一个复杂的机制可以用来控制发送到服务器和从服务器接收的 SOAP 消息的格式。SOAP 规定发送到 XML Web services 和从 XML Web services 发送回的 SOAP 消息的内容必须为 XML 格式。但是，它并没有严格地规定 XML 的格式设置。为了提供一个使用接收不同的格式设置的 XML Web services 的机制，ASP.NET 提供了一个基于属性的机制来控制 SOAP 消息中 XML 的格式。另外，还提供了指定特定元素和通过网络发送的 SOAP 属性名的基于属性的机制，用来在更精细的细节级别上控制 SOAP。 使用 ASP.NET 创建的 XML Web services 和它们的客户端之间的通讯在很大程度上是由两个行业标准规范的：SOAP 和 Web 服务描述语言 (WSDL)。SOAP 为出现在 Body 元素下的数据定义格式设置方案，并为如何在 Body 元素中对参数进行格式设置定义格式设置方案。WSDL 用于描述 XML Web services 所需的 SOAP 消息，WSDL 允许 XML Web services 声明它们接受带有编码参数的 RPC 消息，但它还定义了两个其他术语：Literal 和 Document。Literal（与 Encoded 类似）是指参数的格式设置方式。Document（与 RPC 类似）是指全部 Body 元素的格式设置方式。 下表概述了使用 ASP.NET 创建的 XML Web services 支持的格式设置样式以及完成每个特定组合的属性。带有 Service 后缀的属性可以应用于实现 XML Web services 的类以设置该类中 XML Web services 方法的默认格式设置样式。带有 Method 后缀的属性只能应用于 XML Web services 方法或调用 XML Web services 方法的代理类中的方法。每个组合的详细信息在下表中都有所介绍。 SOAP Document SOAP RPC SOAP SOAP 7 Literal — XSD SoapDocume ntMethod SoapDocume ntService Use=Litera Encoded - SOAP 5 SoapDocume ntMethod SoapDocume ntService Use=Encode d SoapRpcMethod SoapRpcService 设计 XML Web services 时首先要作出的决定之一就是您要如何对 SOAP 请求中的 XML 进行编码。明确地说，您是要 XML 文档严格遵循 XSD 架构还是要遵循 SOAP 规范第 5 节和第 7 节中概述的格式设置规则？SOAP 规范第 5 节和第 7 节中的格式设置规则考虑到了变体。这样，使用 SOAP 编码规则的 SOAP 请求的接收方必须处理所有可能的变体。通过定义 XML Web services 方法的 XSD 架构，可以具体地定义 SOAP 请求中需要发送的确切内容。使用 ASP.NET 创建的 XML Web services 默认为使用基于架构传递的文档。 因为 XML Web services 方法的参数可以组成 SOAP 请求或响应中传递的大部分数据，所以参数映射到 XML 元素的方式决定了 XML 文档的外观。Web 服务描述语言 (WSDL) 定义了两种参数格式设置样式：Encoded 和 Literal。Encoded 是指使用 SOAP 规范第 5 节中概述的 SOAP 编码对参数进行格式设置。Literal 是指使用 l 这是默认值。 每个参数预定义的 XSD 架构将参数映射到 XML 元素。使用 XML Web services 客户端，您可以选择如何将参数映射到 XML 元素以匹配 XML Web services 需要的形式。使用 ASP.NET 创建的 XML Web services 支持 Literal 和 Encoded 两种参数格式设置样式。该支持根据 XML Web services 方法格式设置选择有所变化。 请注意，虽然 ASP.NET 提供了一个广泛的结构用来控制 XML 格式设置的方式，但是并不保证参数序列化的顺序。 我们可以写一个WebService 例子来说明这一点： testSoapParam.asmx: using System; using System.Web.Services; using System.Web.Services.Protocols; using System.Web.Services.Description; using System.Xml; using System.Xml.Schema; using System.Xml.Serialization; using System.Data; public class testEncoded : WebService { [ SoapDocumentMethod(Use=SoapBindingUse.Encoded ,ParameterStyle=SoapParameterStyle.Bare) ] //参数风格为：Encoded 并且是Bare [WebMethod()] public struct1 testStructBareEncode(struct1 a){ return a; } [ SoapDocumentMethod(Use=SoapBindingUse.Encoded ) ]// 参数风格为：Encoded [WebMethod()] public struct1 testStructEncoded(struct1 a){ return a; } [ SoapDocumentMethod(Use=SoapBindingUse.Literal ) ]//参数风格为：Literal [WebMethod()] public struct1 testStructLiteral(struct1 a){ return a; } [ SoapDocumentMethod(ParameterStyle=SoapParamet erStyle.Bare) ]// 参数风格为：Bare [WebMethod()] public struct1 testStructBare(struct1 ddd){ return ddd; } } public class struct1{ public int i=1; public string j="ok"; public struct2 s2; private struct2 temp; public struct2 s4{ get{ return temp; } set{ temp=value; } } } public class struct2{ public String sField; } 当我们运行客户端代理请求SOAP 协议时，我们可以发现不同的参数风格有很大的区别，如使用Literal(默认)和Default 时，SOAP 协议客户端传输给服务端的XML 内容为： ／／参数名字 intstringstringstring 而使用Encoded 时， SOAP 协议客户端传输给服务端的XML 内容为： //a 为参数名，id 号指出该对象是复杂类型，并为链路 intstringstringstring 我们可以发现Encoded 时，SOAP 协议把对象和数组作为复杂类型同其他区分开来，并明确的指明每一个类型的名字。 如果是设置为Bare, SOAP 协议客户端传输给服务端的 XML 内容为: //dd 为参数名 intstringstringstring 我们将它与上面（如果不设置Bare,默认为wrapped）进行比较可以发现它少了一层。 而如果我们将Encoded 和Bare 一起来控制参数时，传输內容变成： ／／第一个参数 intstringstringstring 我们可以发现不仅少一层，而且id 号也变了。 我们不仅可以改变SOAP 协议参数传输的框架，也可以改变具体每一个元素的值，如：[XmlElement（）]可以指定元素的名字和名字空间（namespace）,如果指定了（[ return: XmlElement("ReturnValueElement",IsNullable=fals e)] 和 [XmlElement("MyAddressElement")），则传输的內容变成： ／／指定的元素名字。 intstringstringstring 总之，我们可以根据XML 的序列化来控制SOAP 消息生成XML 內容的形式。

C. 一段IT英语，关于SOAP的RPC风格调用的。谁帮我翻译下。谢谢！

RPC (Remote Procere Call) style, on the other hand, indicates that the SOAP
body contains an XML representation of a method. In order to serialize method
parameters into the SOAP message so that it can be deserialized back by any web
service implementation, the SOAP specification defines a standard set of encoding
rules. As RPC is traditionally used in conjunction with the SOAP encoding rules,
the combination is referred to as RPC/encoded. You also have an RPC/literal
communication style model where you don't have any encoding formats, but still
the messages are limited to RPC method-based communication, where messages
can't be validated as they are not tied to any XML schema definition. You should
probably avoid developing RPC style web services as they have a lot of
interoperability issues.
从另一方面来说，远程过程调录（RPC）风格表明简单对象访问协议（SOAP）主体包含某种方式的可扩展标识语言（XML）代表。为了在简单对象访问协议SOAP通信中连续安排进各种方法参数，以便简单对象访问协议（SOAP)通讯能够被任一网络服务工具执行反序列化操作，简单对象访问协议（SOAP）规格限定了一套标准的编码规则。基于习惯作法是把远程过程调录（RPC）与简单对象访问协议（SOAP）编码规则联合使用，而这种合并方式通常被称为RPC/encoded.您也可以采用一种RPC/文字传播风格模型，在此种模型中您没有任何的编码格式的限制，但是此种模型的各种通信信息仍然受到基于RPC 方式传播的限制。其限制方式主要是通信信息因为没有捆绑在任何XML模式定义上而导致通信信息不能通过验证。您可能最好避免研发RPC风格的各种网络服务项目，因为它们可以导致各种互用性方面的问题。
仅供参考，欢迎指正

D. WEB开发中，使用JSON-RPC好，还是RESTful API好

JSON-RPC比RESTful API好很多。

======

我厌恶restful API如同我厌恶OOP；但与其说我厌恶restful，倒不如说我厌恶鼓吹restful API的一些伪·程序员。

很多鼓吹restful API的程序员，实际上并不理解restful的设计理念，纯粹是在人言亦言，随便看了几篇网文在说restful，自己便也更着鼓吹。

做为一个合格的技术人员，最基础的要求是要对自己所使用的技术有了解，明白各种技术的适用场景，然后因地制宜。

restful首先是要求必须把所有的应用定义成为“resource”，然后只能针对资源做有限的四种操作。

这是对API一个非常糟糕的抽象，有太多现实中需要的API，无法顺当的融入到restful所定义的规范中。

比方说，user login / resetpassword等等。

restful的信徒，他们会说可以根据这个那个规范，把login / password等也纳入为某种资源，然后进行增删改查。这在我看来，纯粹是在解决一些原本不存在，根本不需要解决的问题，纯浪费。

所有的接口，服务器端原本就存在有相应的函数，它们本来就有自身的命名空间，接受的参数、返回值、异常等等。

采用轻便的方式暴露出来即可。

无需把一堆函数重新归纳到“资源”，再削减脑袋把所有的操作都映射为“增删改查”。

对应到web上，rpc的成熟方案非常多，有古老的soap，也有轻量的json rpc。

JSON rpc基本上仅是要求所有的请求必须有msg id，有函数名，然后可定义参数，并且区分返回值与异常；也可定义『命名空间』来对函数模块做划分。

这与大多数语言的模块、函数定义相符，使用起来是非常便利的。

很多json rpc是供web前端ajax调用，若前端调用抽象得当，调用远程API，实际上与调用本地函数无甚区别。

实际上，json rpc也未必需要跟http绑定，即便是在web上，它也可以走web socket，这样子，前端可以使用同一web socket管道批量发送请求，而服务器端乱序返回结果时，前端也可以根据msg id做准确的回调。

websocket，批量调用，乱序返回，这些都可以显著提高API的输出吞吐，这些是在json rpc的设计考量内。

调用更方便，性能也更好，两全其美是完全可能的。

想当然的为了“快”，为了“简单”就必须牺牲别的，这是严重的思维误区。

有些方案，纯粹就是糟糕的方案。

restful API仅适用与业务非常简单的场景，比方说，就是为了提供少量数据表单的增删改查。而这种场景实在是太过简单，实际中几乎找不到。

E. 推荐几款单机RPC类游戏，要大型滴，玄幻类的，科幻类的，战争类的，赛车类的。使命召唤系列，战地系列...

RPG:
上古卷轴5
阿玛拉王国
两个世界2
巫师2
神界2
神鬼寓言3
地牢围攻3
黑暗之魂

龙腾世纪1代2代
猎杀回：恶魔熔炉

第一答圣殿骑士

无主之地2 射击+探索+收集+坐车+打BOSS+玩老虎机

哥特王朝4：阿卡尼亚

崛起2：黑暗水域

潜行游戏:
耻辱

杀手5
细胞分裂5
神偷3

我介绍的全是大作, 而且全部汉化

F. REST风格到底是个什么风格

SocialSite的RESTAPI最近因RoyFielding称其不符合REST风格而受到批评。
Roy说，它是众多自称符合REST风格而实则不然的系统之一。
OpenSocial的RESTAPI是RPC式的，而且是公然宣誓其RPC本性。
它在如此多的方面存在耦合，所以理应将它评为“差”。

G. 街上看到一款带有RPC 字样的淡蓝色包包 谁知道什么牌子的吗附有图片

prich PRICH由Pride&Rich单词组合而成,其中文意思为自尊、骄傲富有、财富。品牌 风格以哈佛、耶回鲁生活方式为基础答,将美国经典风格大众化。该品牌顾客群主要针 对追求时尚、高档、简洁风格的女性。
中文名称一般称作：普利奇

H. rusful风格的webservice是怎么样的格式

一：Web Service基础知识
一个最简单web服务就一个web页面等待请求与处理。更容易理解的方式是Web
Service可以把一个应用变成一个基本WEB方式的请求与处理的应用。常见的两种
Web Service处理方式为：
a. 基于WSDL/SOAP的方式
b. Rest方式
方式a是比较正统的，客户端调用必须先取得WSDL文件，然后生成调用的API才可
以使用。它不是我要说的重点，基本调用流程如下：

方式b是Rest方式，Rest的Web Service的设计原则是基于CRUD，其支持四种操作分
别为：
GET – 获取信息/请求信息内容，绝大多数浏览器获取信息时使用该方式。
POST – 增加信息内容，显示以前的信息内容，可以看作是insert操作
PUT – 更新信息内容，相当与update
DELETE – 删除信息内容可以看作是delete

Rest方式更加简单便捷，如果从设计原则上看HTTP协议本身已经是最Restful风格的
协议了HTTP协议很好的支持了CRUD的操作。正是因为如此，WEB2.0以来, 基于
Restful的Web Service越来越多的成为首选。

二：认识RestfulStyle
Rest的全称是可表述状态迁移(RepresentationalState Transfer), 可能从字面看有点奇怪
HTTP协议本身无状态协议，其保持连接通过设置请求头字段Connection: keep-alive与
设置过期时间来同时控制。其实Rest方式的WebService也是无状态的这样做的好处最少
有以下两个：
1. 更好的负载平衡，减轻服务器端负担
2. 更快的客户端响应，减少不必要的状态检查。

Restful 风格的兴起，要感谢互联网巨头Google,Facebook等他们提供大量基于Restful
风格的web服务，从谷歌地图到天气预报到翻译，国内的互联网巨头腾讯，新浪微博也
发布自己的web服务，吸引更多的开发者加入他们的阵营。Rest除了满足基本的CRUD
设计原则之外，还要遵循如下约定：
1. 资源操作可以通过描述来实现即Representation
2. 消息本身是无状态与自我描述(传输支持XML与JSON)
3. 可以发送与接受多个Representation

Rest风格(Restful Style)架构原则：
1. 客户服务器方式
2. 无状态协议传输
3. 支持缓存
4. 统一接口定义
5. 分层系统设计
这样发布了Rest的Web服务API其改变不会影响到客户端程序与实现。如果你的系统
不能适用Rest风格的架构怎么办，重新设计一个新的架构，扩展Rest风格架构。但是
这个世界上绝大数的系统与应用要做的事情就是CRUD。

三. Rest与HTTP
上面已经提到过HTTP协议可能是最Rest风格的协议，而HTTP1.1协议设计的一个原则
就要实现Rest风格。所以毫无疑问HTTP的GET, POST, PUT, DELETE就是最好的证明
但是Rest风格是否可以应用到其它一些协议与系统设计中嘛，答案是肯定的，一个最好
的例子证明就POP3协议, POP3支持Fetch 数据记录，查询记录，更新记录与删除记录
(记录代表email)多么完美的Rest风格协议。

已经存在的HTTP协议应用：
1. 浏览器客户端(你天天上网，不是IE就是Chrome，或者其它浏览器，你懂的)
2. 即时消息通信，MSN/Skype支持
3. 各种内容管理系统
4. 博客系统与微博客户端应用。
5. 你可以来补充/？

Rest消息详解:
1. 跟我们现在知道的HTTP URI没有什么分别，Google静态地图就是一个很好的例子
只是URL加上不同参数就可以fetch不同的地图内容。
2. 可以支持任何类型的数据传输，这点与基于XML与JSON的信息传输有点同，后者
更希望传输文本内容与结构化文本内容
3. SOAP与XML-RPC有严格的消息格式限制，rest没有消息格式要求。客户端调用方
便啊！

Rest风格Web服务的好处，显然易见一个好处就是简化了客户端的调用，不再像WSDL
那般麻烦。从而减低第三方开发者的学习成本，减短了学习曲线。有利于服务推广与普
及，吸引更多用户数量从而带来潜在的商业利益。

在软件即服务(SaaS - Software As A Service)与软件即平台(PasS-Platform
As A Service)中有着重要的地位与应用。这正是那些互联网巨头对Rest风
格感兴趣的原因之一。

四：Rest风格架构
Rest风格可以用在非WEB的系统设计与架构中嘛/?打答案是肯定的，Rest可以用在任何
系统设计中，从本质是上Rest不是一种技术，而是一种架构原则，当然可以用来架构非
WEB的系统。系统越大风格越要象Rest方式如此才是一个成功的架构。

WEB中的面向对象编程
ExtJS, KendoUI(基于JQuery)等JavaScript库已经支持非常方便的从URL中fetch内容
更新数据，前端设计越来越趋向于更加细化的分层设计，而不仅仅是MVC。客户端
程序员应该更多的专注前台用户体验，由于这些框架良好的封装与可扩展行，
JavaScript等语言编程越来越多的引入面向对象的概念与实践。可以好不夸张的说如
今的JavaScript编程与十年之前已经有本质不同。

I. 什么是 RESTful 到底 REST 和 SOAP，RPC 有何区别

SOAP(Simple Object Access Protocol)简单对象访问协议，是基于HTTP的一种异构系统通信的协议，说白了就是xml文档传输，之所以会内有它，容就是在于不同语言C,C++,JAVA等语言开发的系统进行通信，是WebService就是基于SOAP协议的，确实是一种比较传统的SOA解决方案。 REST(Rerepresentational State Transfer)是外国一位博士提出的一种架构风格，从资源状态转换角度看待资源，但也是基于SOAP协议进行通信。 rest 是一种风格 restful Webservice 和 soap的区别在于表现形式不一样，如果想深入了解 可以去开开 深入理解Webservice 这本书，restful Webservice 不只是可以用json 也可以用xml 更可以用html做消息返回， rest 风格的Webservice 和传统的soap 主要的表现在于 rest是将资源暴露 soap是暴露操作 。具体的流程其实和soap是一样的，但是rest更方便，更轻。

J. 怎么理解rpc和restful架构的风格

这两个不是互斥的，HTTP是不是RPC完全取决于client的具体形式。传统的RPC一般是基于二回进制协议的，client发个答二进制包过来（然后阻塞），server处理完回复一个包，client收到后醒来。在二进制协议中一般可以在包中加个id来指明回复和请求的对应