restfulphp
‘壹’ 如何处理restful对接口安全性问题
REST (REpresentation State Transfer) 描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，他是 HTTP 规范的主要编写者之一。REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个惟一的地址。所有资源都共享统一的界面，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。另一个重要的 REST 原则是分层系统，这表示组件无法了解它与之交互的中间层以外的组件。通过将系统知识限制在单个层，可以限制整个系统的复杂性，促进了底层的独立性。当REST 架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。RESTful的实现:RESTful Web 服务与 RPC 样式的 Web 服务了解了什么是什么是REST，我们再看看RESTful的实现。最近，使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封(包括方法和参数信息)通过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务，URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。由于轻量级以及通过 HTTP 直接传输数据的特性，Web 服务的 RESTful 方法已经成为最常见的替代方法。可以使用各种语言(比如 java 程序、Perl、Ruby、Python、php 和 Javascript[包括 Ajax])实现客户端。RESTful Web 服务通常可以通过自动客户端或代表用户的应用程序访问。但是，这种服务的简便性让用户能够与之直接交互，使用它们的 Web 浏览器构建一个 GET URL 并读取返回的内容。在REST 样式的 Web 服务中，每个资源都有一个地址。资源本身都是方法调用的目标，方法列表对所有资源都是一样的。这些方法都是标准方法，包括 HTTP GET、POST、PUT、DELETE，还可能包括 HEADER 和 OPTIONS。在RPC 样式的架构中，关注点在于方法，而在 REST 样式的架构中，关注点在于资源 -- 将使用标准方法检索并操作信息片段(使用表示的形式)。资源表示形式在表示形式中使用超链接互联。Leonard Richardson 和 Sam Ruby 在他们的着作 RESTful Web Services 中引入了术语 REST-RPC 混合架构。REST-RPC 混合 Web 服务不使用信封包装方法、参数和数据，而是直接通过 HTTP 传输数据，这与 REST 样式的 Web 服务是类似的。但是它不使用标准的 HTTP 方法操作资源。它在 HTTP 请求的 URI 部分存储方法信息。好几个知名的 Web 服务，比如 Yahoo 的 Flickr API 和 del.icio.us API 都使用这种混合架构。RESTful的实现:RESTful Web 服务的 Java 框架有两个 Java 框架可以帮助构建 RESTful Web 服务。erome Louvel 和 Dave Pawson 开发的 Restlet(见 参考资料)是轻量级的。它实现针对各种 RESTful 系统的资源、表示、连接器和媒体类型之类的概念，包括 Web 服务。在 Restlet 框架中，客户端和服务器都是组件。组件通过连接器互相通信。该框架最重要的类是抽象类 Uniform 及其具体的子类 Restlet，该类的子类是专用类，比如 Application、Filter、Finder、Router 和 Route。这些子类能够一起处理验证、过滤、安全、数据转换以及将传入请求路由到相应资源等操作。Resource 类生成客户端的表示形式。JSR-311是 Sun Microsystems 的规范，可以为开发 RESTful Web 服务定义一组 Java API。Jersey是对 JSR-311 的参考实现。JSR-311 提供一组注释，相关类和接口都可以用来将 Java 对象作为 Web 资源展示。该规范假定 HTTP 是底层网络协议。它使用注释提供 URI 和相应资源类之间的清晰映射，以及 HTTP 方法与 Java 对象方法之间的映射。API 支持广泛的 HTTP 实体内容类型，包括 HTML、XML、JSON、GIF、JPG 等。它还将提供所需的插件功能，以允许使用标准方法通过应用程序添加其他类型。RESTful的实现:构建 RESTful Web 服务的多层架构RESTful Web 服务和动态 Web 应用程序在许多方面都是类似的。有时它们提供相同或非常类似的数据和函数，尽管客户端的种类不同。例如，在线电子商务分类网站为用户提供一个浏览器界面，用于搜索、查看和订购产品。如果还提供 Web 服务供公司、零售商甚至个人能够自动订购产品，它将非常有用。与大部分动态 Web 应用程序一样，Web 服务可以从多层架构的关注点分离中受益。业务逻辑和数据可以由自动客户端和 GUI 客户端共享。惟一的不同点在于客户端的本质和中间层的表示层。此外，从数据访问中分离业务逻辑可实现数据库独立性，并为各种类型的数据存储提供插件能力。图1 展示了自动化客户端，包括 Java 和各种语言编写的脚本，这些语言包括 Python、Perl、Ruby、PHP 或命令行工具，比如 curl。在浏览器中运行且作为 RESTful Web 服务消费者运行的 Ajax、Flash、JavaFX、GWT、博客和 wiki 都属于此列，因为它们都代表用户以自动化样式运行。自动化 Web 服务客户端在 Web 层向 Resource Request Handler 发送 HTTP 响应。客户端的无状态请求在头部包含方法信息，即 POST、GET、PUT 和 DELETE，这又将映射到 Resource Request Handler 中资源的相应操作。每个请求都包含所有必需的信息，包括 Resource Request Handler 用来处理请求的凭据。从Web 服务客户端收到请求之后，Resource Request Handler 从业务逻辑层请求服务。Resource Request Handler 确定所有概念性的实体，系统将这些实体作为资源公开，并为每个资源分配一个惟一的 URI。但是，概念性的实体在该层是不存在的。它们存在于业务逻辑层。可以使用 Jersey 或其他框架(比如 Restlet)实现 Resource Request Handler，它应该是轻量级的，将大量职责工作委托给业务层。Ajax 和 RESTful Web 服务本质上是互为补充的。它们都可以利用大量 Web 技术和标准，比如 HTML、JavaScript、浏览器对象、XML/JSON 和 HTTP。当然也不需要购买、安装或配置任何主要组件来支持 Ajax 前端和 RESTful Web 服务之间的交互。RESTful Web 服务为 Ajax 提供了非常简单的 API 来处理服务器上资源之间的交互。图1 中的 Web 浏览器客户端作为 GUI 的前端，使用表示层中的 Browser Request Handler 生成的 HTML 提供显示功能。Browser Requester Handler 可以使用 MVC 模型(JSF、Struts 或 Spring 都是 Java 的例子)。它从浏览器接受请求，从业务逻辑层请求服务，生成表示并对浏览器做出响应。表示供用户在浏览器中显示使用。表示不仅包含内容，还包含显示的属性，比如 HTML 和 CSS。 业务规则可以集中到业务逻辑层，该层充当表示层和数据访问层之间的数据交换的中间层。数据以域对象或值对象的形式提供给表示层。从业务逻辑层中解耦 Browser Request Handler 和 Resource Request Handler 有助于促进代码重用，并能实现灵活和可扩展的架构。此外，由于将来可以使用新的 REST 和 MVC 框架，实现它们变得更加容易，无需重写业务逻辑层。数据访问层提供与数据存储层的交互，可以使用 DAO 设计模式或者对象-关系映射解决方案(如 Hibernate、OJB 或 iBATIS)实现。作为替代方案，业务层和数据访问层中的组件可以实现为 EJB 组件，并取得 EJB 容器的支持，该容器可以为组件生命周期提供便利，管理持久性、事务和资源配置。但是，这需要一个遵从 Java EE 的应用服务器(比如 JBoss)，并且可能无法处理 Tomcat。该层的作用在于针对不同的数据存储技术，从业务逻辑中分离数据访问代码。数据访问层还可以作为连接其他系统的集成点，可以成为其他 Web 服务的客户端。数据存储层包括数据库系统、LDAP 服务器、文件系统和企业信息系统(包括遗留系统、事务处理系统和企业资源规划系统)。使用该架构，您可以开始看到 RESTful Web 服务的力量，它可以灵活地成为任何企业数据存储的统一 API，从而向以用户为中心的 Web 应用程序公开垂直数据，并自动化批量报告脚本。什么是REST:结束语REST 描述了一个架构样式的互联系统(如 Web 应用程序)。REST 约束条件作为一个整体应用时，将生成一个简单、可扩展、有效、安全、可靠的架构。由于它简便、轻量级以及通过 HTTP 直接传输数据的特性，RESTful Web 服务成为基于 SOAP 服务的一个最有前途的替代方案。用于 web 服务和动态 Web 应用程序的多层架构可以实现可重用性、简单性、可扩展性和组件可响应性的清晰分离。Ajax 和 RESTful Web 服务本质上是互为补充的。
‘贰’ php开发restful式api中，客户端的登录，验证机制如何该设置
oauth的令牌机制还是很适合api的身份验证的 实际上就是一种SESSION的变种
本身也没多少难度 就是按照预先几个平台约定的key ，请求端通过发送key加某个规则(比如平台id)加密后构成的签名码，发送到服务器端，服务器根据提供的身份参数查询获得预先约定好的key 再用key加规则(比如平台id)加密后确定无误就算通过 ：很像密码验证吧。
然后给对方返回一个无序的加密字符串，就是令牌啦。令牌要存在服务器上，一般存数据库里和平台请求的来源对应，设置有效期保存。
客户端拿到这个令牌后就可以通过令牌访问了，（和SESSION几乎一模一样）在服务器上交互，只需要验证令牌的正确性和有效期，就可以放行进行操作了。
大致如此，细节有很多变化，机制运作差不多就这个样子。
‘叁’ php 哪个restful框架好用
Yii框架
Yii是一个基于组件、用于开发大型 Web 应用的 高性能 PHP 框架。Yii 几乎拥有了 所有的特性 ，包括 MVC、DAO/ActiveRecord、I18N/L10N、caching、基于 JQuery 的 AJAX 支持、用户认证和基于角色的访问控制、脚手架、输入验证、部件、事件、主题化以及 Web 服务等等。Yii 采用严格的 OOP 编写，Yii 使用简单，非常灵活，具有很好的可扩展性。
yii中文社区：http://www.yiichina.com/
‘肆’ php restful api怎么用
Wax for iPhone这种框架在开发时，旨在把Lua脚本语言和原生Objective-C应用编程接口(API)结合起来。这意味着，你可以从Lua里面，使用任何和全部的Objective-C类及框架。
从技术上来讲，Wax结合了Objective-C类和原生C代码。Lua语言嵌入了C语言，然后Objective-C类并入到其中。
为什么使用Wax
Wax是免费的、开源的。与其他一些基于Lua的移动开发解决方案不同，Wax是个开源框架，只需要你花一点点时间就可以上手，不需要花钱。不喜欢Wax的工作方式，或者发现实施方面的缺陷源代码可免费获取，你总是可以改动源代码，以满足自己的需要。
可以利用原生API。这意味着，为教Objective-C而编写的教程很容易由Lua for Wax来改动和编写。这还意味着，你的应用程序在外观感觉上总是如同原生应用程序，不过又得到了用Lua这种高效脚本语言编写代码可以节省时间的好处。
可以使用Xcode。这意味着，模拟器和设备部署都轻而易举，不会轻易与未来的iOS版本决裂。
可以利用所有现有的Objective-C库。如果你有一个Objective-C类是以前编写的，不需要改动，就可以将它用在Lua中——只要把它放入到Xcode。Three20之类的库也是一样。只要按照正常指令来添加库，就可以使用Lua代码访问它们。
可以利用Wax Lua模块。Wax有几个内置的Lua模块，使得异步HTTP请求和JavaScript对象标注(JSON)创建/解析极其容易而快速(因为模块是用C编写的)。
没必要管理内存。不再需要操心内存分配之类的事务。Wax为你处理这一切。
Lua类型自动转换成对应的Objective-C类型，反之亦然。 这意味着，如果你调用了需要NSString和NSInteger的某个方法，但传送了Lua字符串和Lua整数，Wax会为你搞定转换工作。这种转换功能强大，甚至可以处理复杂的Objective-C特性，比如选择器。这样就行，我刚在后盾网问老师的，希望能帮到你。Ψ(￣(ｴ)￣)Ψ努力吧
‘伍’ 把传统的PHP Web接口改成符合RESTful风格的Web接口有什么用处
更符合HTTP协议的标准，主要是为了接口项目的标准化，资源可视化。你可以去研究一下HTTP标准，能有更深的理解。不过在项目中，REST也不是必须的，这是一个更好的选择而已，你可以当做命名规范，设计规则之类的去理解
‘陆’ 不明白php的restful，有什么实际用处吗
我理解你的问题应该是“把传统的PHP Web接口改成符合RESTful风格的Web接口有什么用处？”
其实，这里最好用“好处”这个词来代替“用处”，因为传统的Web接口实现方式同样能够实现业务需要（所以这不是一个必须的事情，需要自己根据业务需求综合判断是否需要采用），而改用“RESTful风格”会有一些额外的“好处”：
统一的风格能够让各方更加便利的进行交互，也带来了更好的兼容性（这是一个所有遵循一定规范所带来的共通的好处，就像大家都说普通话，交流起来多方便啊）
对资源的操作正好对应相应的HTTP动作（GET、POST、PUT、DELETE），而这些动作正好可以满足我们对资源状态进行操作的需要，也就是说想对资源状态进行什么样的操作就选择什么样的动作，而这些动作又是HTTP协议本身提供的，多么和谐自然啊（就是题主的摘录内容）
请求所造成的影响明确，或者说副作用明确，比如GET肯定是安全的，PUT和DELETE肯定是幂等得，POST肯定是不安全的（这里的肯定是建立在API设计完全遵循“RESTful风格”基础上的）
良好的符合“RESTful风格”的URI设计，可以让Web接口的功能和整体结构更加清晰，仅仅通过URI就能方便的推测出来接口是做什么的，以及多个资源之间关联性
利用HTTP内容协商（content negotiation）实现资源的多重表述，比如请求方可以把自己需要的格式放到头信息的Accept字段中表述（如Accept: text/json），这样同样一个URI就可以输出多种格式而不再需要在URI里面特别加上一个type=json的参数了
客户端、代理服务器等可以根据HTTP协议规范进行相应的额外处理，比如Cache
... 可能还有我没总结到的好处(当然也会有一些不足~~)
‘柒’ PHP如何编写RESTful接口的方法实例演示
就收参数
处理参数
返回json格式数据
‘捌’ 如何使用PHP搭建一个restFul风格的API系统
单入口，常见使用index.php，一般设置全局常量和debug模式
2、统一路由格式，带上版本号，并尽量采用映射的模式，比如：/v0/proct => /mole/controller/action
3、GET,POST,PUT,DELET,PATCH等常见的请求，采用$_POST,$_GET或者php://input的方式获取传来的数据。
你可以去后盾人平台看一下，里面的东西不错
‘玖’ LAMP系统部署RESTful API应该用JAVA、PHP还是ASP.net
java和php都可以，建议按自己容易掌握的做，一般php入门相对容易。
php和java都有现成的框架做api，
例如php有laravel和yii等框架，国内有thinkphp框架，在框架下面写会比从0开始写好很多。
你的apache, centos, mariadb, php，已经满足php运行环境要求。
asp.net每次都要编译，相对较慢，但如果你已经有c#基础和html开发，应该这个也可以。asp.net也有类似的开源开发框架，但数量较少。
多动手，多试试，祝好运！
‘拾’ 什么是 RESTful 到底 REST 和 SOAP，RPC 有何区别
第一个问题：什么是RESTful？
REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。有兴趣可以看看这里论文`，谁是Fielding?点击前面名字了解。
那RESTful到底是什么呢？简单的讲，它是：一种架构设计风格，提供了设计原则和约束条件，而不是架构。而满足这些约束条件和原则的应用程序或设计就是 RESTful架构或服务。
推荐阅读：
张善友博客——REST 入门介绍
infoq——深入浅出REST
第二个问题：到底 REST 和 SOAP、RPC 有何区别？
这个问题比较大，要知道他们有什么区别首先需要明白，他们分别是什么？
REST上面已经简单的说明了它是什么。
SOAP(简单对象访问协议)是什么？SOAP是一种数据交换协议规范，是一种轻量的、简单的、基于XML的协议的规范。它有什么优点？简单总结为： 易用，灵活，跨语言，跨平台。
易用：是因为它的消息是基于xml并封装成了符合http协议，因此,它符合任何路由器、 防火墙或代理服务器的要求。
灵活：表现在极具拓展性，SOAP 无需中断已有的应用程序, SOAP 客户端、 服务器和协议自身都能发展。而且SOAP 能极好地支持中间介质和层次化的体系结构。
跨语言：soap可以使用任何语言来完成，只要发送正确的soap请求即可。
跨平台：基于soap的服务可以在任何平台无需修改即可正常使用。
RPC(远程调用框架) 是一种允许分布式应用程序调用网络上不同计算机的可用服务的机制。涉猎不多，一下省略256个字。有熟悉的朋友可以在评论补充，然后我会修改到该内容中去
从上面我们可以看出，REST 和 SOAP、RPC 有何区别呢？没什么太大区别，他们的本质都是提供可支持分布式的基础服务，最大的区别在于他们各自的的特点所带来的不同应用场景。
REST可以看着是http协议的一种直接应用，默认基于json作为传输格式，使用简单，学习成本低效率高，~~但是安全性较低~~，而SOAP可以看着是一个重量级的协议，基于xml，SOAP在安全方面是通过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经得到了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持 。这是REST薄弱的地方。