网站即软件
服务器君一共花费了148.725 ms进行了4次数据库查询，努力地为您提供了这个页面。
试试阅读模式？希望听取您的建议
越来越多的人开始意识到，网站即软件，而且是一种新型的软件。这种"互联网软件"采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时（high latency）、高并发等特点。
网站开发，完全可以采用软件开发的模式。但是传统上，软件和网络是两个不同的领域，很少有交集；软件开发主要针对单机环境，网络则主要研究系统之间的通信。互联网的兴起，使得这两个领域开始融合，现在我们必须考虑，如何开发在互联网环境中使用的软件。
RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。但是，到底什么是RESTful架构，并不是一个容易说清楚的问题。下面，我就谈谈我理解的RESTful架构。
REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。
Fielding是一个非常重要的人，他是HTTP协议（1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。所以，他的这篇论文一经发表，就引起了关注，并且立即对互联网开发产生了深远的影响。
他这样介绍论文的写作目的：
"本文研究计算机科学两大前沿----软件和网络----的交叉点。长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。"
(This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. )
Fielding将他对互联网软件的架构原则，定名为REST，即Representational State Transfer的缩写。我对这个词组的翻译是"表现层状态转化"。
如果一个架构符合REST原则，就称它为RESTful架构。
要理解RESTful架构，最好的方法就是去理解Representational State Transfer这个词组到底是什么意思，它的每一个词代表了什么涵义。如果你把这个名称搞懂了，也就不难体会REST是一种什么样的设计。
3. 资源（Resources）
REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。
4. 表现层（Representation）
"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。
比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。
URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。
5. 状态转化（State Transfer）
访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。
互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
综合上面的解释，我们总结一下什么是RESTful架构：
每一个URI代表一种资源；
客户端和服务器之间，传递这种资源的某种表现层；
客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
RESTful架构有一些典型的设计误区。
最常见的一种设计错误，就是URI包含动词。因为"资源"表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。
举例来说，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。
如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：POST /accounts/1/transfer/500/to/2
正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务：
POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
另一个设计误区，就是在URI中加入版本号：
http://www.nowamagic.net/app/1.0/foo
http://www.nowamagic.net/app/1.1/foo
http://www.nowamagic.net/app/2.0/foo
因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分（参见Versioning REST Services）：
Accept: vnd.nowamagic-net.foo+ version=1.0
Accept: vnd.nowamagic-net.foo+ version=1.1
Accept: vnd.nowamagic-net.foo+ version=2.0
本文地址：，欢迎访问原出处。
不打个分吗？
转载随意，但请带上本文地址：
如果你认为这篇文章值得更多人阅读，欢迎使用下面的分享功能。
小提示：您可以按快捷键 Ctrl + D，或点此 。
大家都在看
现代魔法研究协会欢迎你
阅读一百本计算机著作吧，少年
布莱恩特(Randal E.Bryant) (作者), 奥哈拉伦(David R.O'Hallaron) (作者), 龚奕利 (译者), 雷迎春 (译者)
《深入理解计算机系统》从程序员的视角详细阐述计算机系统的本质概念，并展示这些概念如何实实在在地影响应用程序的正确性、性能和实用性。全书共12章，主要内容包括信息的表示和处理、程序的机器级表示、处理器体系结构、优化程序性能、存储器层次结构、链接、异常控制流、虚拟存储器、系统级I/O、网络编程、并发编程等。书中提供子大量的例子和练习题，并给出部分答案，有助于读者加深对正文所述概念和知识的理解。
扫一扫，在手机上阅读
栏目最新博文
18,764 views
14,007 views
8,533 views
8,214 views
10,560 views
8,669 views
6,109 views
6,670 views
9,178 views
6,706 views
栏目博文推荐
6,060 views
7,249 views
13,595 views
6,109 views
5,098 views
4,299 views
8,018 views
4,457 views
9,841 views
8,669 views
治疗拖延症最好的方法就是立刻开始。
关于网站与作者
互联网信息太多太杂，各互联网公司不断推送娱乐花边新闻，SNS，微博不断转移我们的注意力。但是，我们的时间和精力却是有限的。这里是互联网浩瀚的海洋中的一座宁静与美丽的小岛，供开发者歇息与静心潜心修炼（愿景）。
“Veda”的本义是知识、启示，希望这里能为开发者提供充足的技术资料。
我的电子邮件gonnsai(，腾讯微博：，欢迎与我联系。[译]RESTful中不同HTTP请求类型的含义 - 简书
[译]RESTful中不同HTTP请求类型的含义
原文地址：
RESTful web服务在设计上非常依赖于HTTP。通过使用不同的HTTP方法来完成工作，使用HTTP的响应代码来同时用户一个请求是否成功。RESTful表示Representational State tranfer，使用HTTP来实现两个系统之间通信。RESTful web服务是一些指向资源的URI（统一资源标识符）的集合。这些URI可以指向一个资源或者多个资源的集合。比如说，/employee/101包含的是员工101的详细信息，而/employees会返回所有员工的列表。在RESTful web服务中，HTTP请求类型表示要对资源进行的操作。
例如：使用HTTP GET请求访问/employee/101，可以取回该用户的详细信息。使用POST请求访问/employee/102，将会创建一个ID为102的新员工。、使用PUT请求访问/employee/101，可以用来更新员工101的信息。使用DELETE请求访问/employee/101，可以删除ID为101的员工的数据。
在使用PUT和POST请求的时候，具体的数据将会包含在请求体中。
Purpose of HTTP Request in RESTful WebService
当使用RESTful web服务的时候，每一种HTTP请求方法的含义如下：
从服务器取回数据（只是取回数据，而不会产生其他的影响）。这是一个幂等的方法（译者注：使用相同的参数重复执行，应该能够获取到相同的结果）。下面是一个使用GET请求从服务器获取id为123的书的例子：
GET /books/123
POST请求通常用来创建一个实体，也就是一个没有ID的资源。一旦这个请求成功执行了，就会在HTTP请求的响应中，返回这个新创建的实体的id。我们通常用它来上传文件或者表单。比如，下面这个URL将会在服务器上创建一本新书：
POST /books/
PUT请求和POST请求类似，但是一般用来更新一个已有的实体。通过把已经存在的资源的ID和新的实体用PUT请求上传的服务器，来更新资源。比如，下面这个URL将会替换掉服务器上的ID为123的书：
PUT /books/123
可以参考Leonard Richardson, Sam Ruby, and David Heinemeier Hansson写的RESTful Web Services，来了解RESTful API中什么时候该使用PUT和POST。
DELETE方法用来从服务器上删除资源。和PUT类似，你需要把要删除的资源的ID上传给服务器。比如下面这个URL可以用来删除服务器上ID为123的书：
DELETE /books/123
提供一种方法来测试当一个请求发生的时候，服务器通过网络收到的内容。所以，它会返回你发送的内容。
HEAS请求和GET请求资源类似，但是仅仅返回响应的头部（没有具体的响应体）。同时，和GET请求类似，HEAD也是幂等的，不会在服务器上造成其他影响。
OPTIONS方法允许客户端请求一个服务所支持的请求方法。它所对应的响应头(response header)是Allow, 它非常简单地列出了支持的方法。(以下例子为译者添加)比如：
Allow: HEAD,GET,PUT,DELETE,OPTIONS
主要用来建立一个对资源的网络连接（通常请求一些能够把HTTP连接转发成为TCP连接并保持的代理）。一旦建立连接后，会响应一个200状态码和一条“Connection Established”的消息。
下面这张图展示了在RESTful web服务中，不同的HTTP方法的用法：
不同HTTP方法 的用法
以上就是在RESTful web服务中不同HTTP请求类型的含义，不管是在Java中还是在其他技术中。最重要的是理解PUT和POST之间的区别，尽管PUT和POST都可以用来创建和更新实体，但是通常更倾向于使用POST来创建，而使用PUT来更新已存在的实体。
北京交通大学 计算机与信息技术学院RESTful web Service介绍及参数详解
我的图书馆
RESTful web Service介绍及参数详解
表征状态传输(Representational State Transfer(REST) )是一个软件架构风格，该架构围绕Http协议上数据的传输，使用http的那四个谓词：get,put,serice.delete.这个架构也避免了 对诸如：SOAP envelope这样的附加包装器的使用以及任何状态数据的使用。概要：REST是一个架构风格，首次在一个博士论文中被描述，该博士是Roy Fielding。在RESTful系统中，服务器利用URI暴露资源，客户端使用四个Http谓词来访问资源。由于客户端接收了资源，他们被置于某种状 态。当他们访问一个新的资源，通常是点击下一个连接，他们改变了，或者说是过渡了他们的状态。为了工作，REST假设资源是能够使用普遍的标准语法来代表 的。3W网络是最普及的例子，他是最大的基于REST策略构建的系统。web浏览器作为客户端访问驻留在web服务器上的资源。资源通过HTML或者xml体现，所有的web浏览器可以消费它。浏览器可以很容易的根据连接跳转到新的资源上面。RESTful系统的优势在于他们可以高伸缩性和高灵活性。因为被访问和操作的资源是通过http谓词。资源通过URI被暴露，资源被通过标准的语 法体现，客户端不会被服务器所影响。也就是说，RESTFul系统可以充分体现http的可伸缩性特性，比如：缓存和代理特性。基础REST策略：RESTful架构坚持下面的基本原则：应用程序状态和功能被分离到不同资源中。资源是可以定位的通过标准URLs,并且这个URLs可以作为超媒体连接。所有资源可以被http谓词所使用：delete,get,post,put所有资源提供信息通过MIME类型（该类型被HTTP支持）协议是无状态的协议是可缓存的协议是分层的&资源：资源是REST的中心，一个资源是信息源，可以被URI来标注的。在web的早期，资源是大量的静态文档，在当下，一个资源可以是任何信息源，例如web Service可以是一个资源如果他能够通过一个URI来被访问。RESTful端点交换他们代表的资源。一个代表可以使一个包含了数据的文档。例如：web Service的方法提供了访问客户的记录，那么该方法就是资源，在服务和消费者之间传输的客户信息拷贝，也是资源的代表。REST最佳实践：当设计一个RESTful服务时，最佳实践有如下帮助：提供一个不一样的URI给每个你希望暴露的资源。&&&&&&& 例如：如果你在建立一个系统，该系统处理驾驶记录，每个记录将有个唯一的URI，如果这个系统提供违规停车和超速罚款记录，每个资源的类型应该也有一个唯一的基准。例如：超速罚款应该通过/speedingfines/driverID来访问，而违规停车应该通过/parkingfines/driverID来访问。在URIs中使用声明：使用nouns突出显示资源是事情而不是动作这件事实。URLs诸如：/ordering隐喻了行为，而/orders隐喻了事情get对应的方法应该不去改变任何数据。在应答里使用链接：&&&&&&&&& 放入去向别的资源的链接到应答里，可以使客户端跟从一个数据链变得容易。例如，如果你的服务返回一个资源集合，对于客户单来说，更容易访问每个独立的资 源，使用提供的连接，如果连接不被包含在response里面，客户端需要附加的逻辑来跟从这个去向特定节点的连接。&使服务无状态&&&&&&&& 需要客户端或者服务端维护状态信息，导致两者的紧耦合，紧耦合会让升级和迁移变得更困难。维护状态也会使从通信错误中还原状态变得更麻烦。设计一个RESTful web Service:&&&&&&&& 要执行以下步骤：定义服务将要暴露的资源：通常，一个服务将暴露一个或多个资源，这些资源会组织成一个树，例如：一个驾驶记录服务被组织成三个资 源：/license/driverID ,/license/driverID/speedingfines,/license/driverID/parkingfines定义在每个资源上执行的动作，例如：你可能想更新驾驶员地址或者删除停车罚单从一个驾驶员记录中。映射行为到何时的http谓词。一旦你定义好了服务，你就可以使用FUSE Services Framework去实现它了。采用Fuse Services Framework实现REST&&&&&&&&&& FSF提供RESTful Web Service的java API的实现。JAX-RS提供标准的方式去映射POJO到资源中去，使用annotations。当从一个抽象的服务定义转移到使用JAX-RS实现RESTFul Web Services实现，你需要做：&&& 1.创建根资源类给资源，该根资源类代表了服务资源树的顶端。&&& 2.映射服务的其他资源到树的子资源节点上。&&& 3.创建方法来实现每个http谓词。Data bindings：&&&&&&& 默认情况下，FSF使用JAXB对象来映射资源与他的java object。提供清晰，定义良好的映射，在对象和xml元素之间。&&&&& FSF实现也支持交换数据采用JSON，JSON是一种被Ajax开发者广泛使用的数据格式。在json和jaxb之间数据的编组被FSF运行时动态处理。&chapter2：创建资源在RESTFul web&Service中，所有的请求被资源所处理。JAX-RS API上实现了将资源看成java类。一个资源类是一个Java类，他被一个或多个RAX-RS注解所标注。用JAX-RS实现的一个RESTFul web Service的核心是一个根资源类。根资源类是被暴露的服务的资源树的入口点。他可以自己处理所有的请求，或者他可以提供对子起源的访问通道。&介绍：使用JAX-RS APIs实现的RESTFul WEb Services提供应答作为资源代表，该代表实现了java类。一个资源类是一个类，该类使用了JAX-RS注解来实现一个资源。对于大多数 RESTful web services来说，他就是一个需要被访问的资源集合。资源类的注解提供了信息诸如：资源的URI和每个操作处理的谓词。资源类型：JAX-RS APIs允许你创建两个基本类型的资源：根资源类：是服务资源树的入口点，他被装饰（用@path注解），用以定义服务中资源的基准URI。子资源：通过根资源来访问的资源，他们被装饰了@path注解的方法所实现。一个子资源的@path注解定义了相对于基准URI的路径。例子：简单资源类：package demo.jaxrs.
import javax.ws.rs.GET; import javax.ws.rs.P import javax.ws.rs.PathP
@Path("/customerservice")
public class CustomerService {
public CustomerService()
public Customer getCustomer(@QueryParam("id") String id)
... }基本的JAX-RS 注解&概述：RESTful web service实现最最基本的信息片是：服务资源的URI一个class的方法如何被映射到http谓词上。JAX-RS定义了一组注解来提供基本的信息。所有的资源类必须有至少一个注解。设置路径：@path注解指明了一个资源的URI，该注解定义在Javax.ws.rs.Path接口中。它既可以用来包装一个资源类，也可以用来包装一个资 源的方法。它用一个字符串作为唯一参数（可参看上面的代码）。该字符串是一个URI的形式，指明了被实现资源的location。URI模板指明了资源的相对路径，如下所示：模板包括未处理的路径组件被{}包围的参数指示符：参数指示符可以包括通常的表达式来替换缺省的路径@Path("resourceName/{param1}/../{paramN}")例如：URI模板：widgets/{color}/{number}将映射到widgets/blue/12.参数color的值是blue,number参数的值是12.URI模板怎样映射到一个完整的URI，依赖于@Path注解包装的是什么东东，如果@path在根资源类中（注解包装的是根资源类），那么URI模板是所有资源的根URI,并且他被直接添加到服务发布的URI中。如果注解是封装一个子资源类，它将相对于根资源的URI。指定HTTP 谓词：JAX-RS使用五个注解来指定http谓词，这些谓词使用在方法上。javax.ws.rs.DELETE指明了方法映射到DELETEjavax.ws.rs.GET指明方法映射到GETjavax.ws.rs.POST指明方法映射到postjavax.ws.rs.PUT指明方法映射到putjavax.ws.rs.HEAD指明方法映射到HEAD当映射方法到http谓词，你必须确保映射是有意义的。例如，入股你映射一个要提交订单的方法，你应当映射他到一个put或者post谓词。如果映射它到一个get或者delete谓词，将导致不可以预计的情况发生。根资源类：概述：根资源类是一个JAX-RS实现的RESTful服务的入口点，它被@path包装，指示出组成服务的所有资源的根URI。他的方法直接实现在资源上的操作或者提供一个访问其他子资源的通道。需求：一个类为了成为根资源类，它必须符合下面的规则：类必须被@path包装&&&&&&&& 指定的路径是根URI对于所有实现服务的资源来说。如果根资源类指明它的路径是wiggets并且一个方法实现了GET谓词，然后一个在wedgets上 的GET调用将调用该方法。如果子资源指明了他的URI是{id},那么完整的URI模板对于子资源来说，就是widgets/{id}，并且他将处理形 如widgets/12和widgets/42这样的请求。类必须有一个公用的构造器用于运行时被调用&&&&&&& 运行环境必须能够提供构造器所需的所有参数。构造器的参数可以包括被JAX-RS参数注解包装的参数。至少有一个类方法必须被HTTP谓词注解所包装或者被@path所包装下例现实了一个根资源类提供一个访问子资源类的通道：package demo.jaxrs.
import javax.ws.rs.DELETE; import javax.ws.rs.GET; import javax.ws.rs.POST; import javax.ws.rs.PUT; import javax.ws.rs.P import javax.ws.rs.PathP import javax.ws.rs.QueryP import javax.ws.rs.core.R
@Path("/customerservice/")
public class CustomerService {
public CustomerService()
public Customer getCustomer(@QueryParam("id") String id)
public Response deleteCustomer(@QueryParam("id") String id)
public Response updateCustomer(Customer customer)
public Response addCustomer(Customer customer)
@Path("/orders/{orderId}/")
public Order getOrder(@PathParam("orderId") String orderId)
}resource 方法的工作原理&概述：资源方法被JAX-RS注解所注释。他们有HTTP方法注解之一来指明方法处理哪种类型的请求，JAX-RS放置了约束在资源方法上。普通约束：所有的资源方法必须符合以下条件必须是public的必须被HTTP方法注解所包装不能有多于一个的实体参数参数：资源方法参数采取两种形式：实体参数-实体参数是无注解的，他们的值和request的body对应，一个实体参数可以使任意类型的，所以应用城西得有一个实体提供器。通常是JAXB对象。被注解的参数：被注解的参数使用一个JAX-RS注解来指明参数值是如何映射到请求的。通常，参数值映射的是request URI的一部分。如下例：实现了一个资源方法，它具有有效的参数列@POST @Path("disaster/monster/giant/{id}") public void addDaikaiju(Kaiju kaiju,
@PathParam("id") String id) {
... }如下例，实现了一个资源方法，他具有无效的参数列&@POST @Path("disaster/monster/giant/") public void addDaikaiju(Kaiju kaiju,
String id) {
... }返回值：资源方法可以返回以下类型的值void任何java class：如果是返回javaclass，那么应用程序必然有一个实体提供者。一个Response。一个GenericEntity&T&类型的对象所有的资源方法返回一个HTTP状态代码给请求端。当方法的返回类型是void或者返回值是null时，资源方法设置状态代码为200，当资源方法返回值不是null，它设置状态值为204.子资源的工作原理概述：实际情况下，一个服务要处理很多资源。例如，在一个订单处理服务的最佳实践中，支持每个客户作为唯一资源来被处理，每个订单也作为唯一资源来被处理。使用JAX-RS APIs，可以将客户资源和订单资源作为子资源来处理。一个子资源就是要通过根资源才能访问的资源。通过增加@path注解到一个类方法来定义一个资源是子资源。子资源可以由两条途径来实现：子资源方法-直接实现一个http谓词，被一个注解所包装子资源定位-只想一个实现子资源的类说明子资源：子资源通过用@path包装一个方法来指明。子资源的URI结构如下：1.追加子资源的@path注解值到子资源的父资源的@path注解值后面。&& 父资源的@path注解也许被找到在资源类的一个方法哪里，该方法返回一个对象，该对象包含了子资源。2.重复前面的步骤直到根资源被触及。3.被组装的URI被追加到基准URI上。@Conumes 和 @Proces@Consumes&注释代表的是一个资源可以接受的 MIME 类型。@Produces&注释代表的是一个资源可以返回的 MIME 类型。这些注释均可在资源、资源方法、子资源方法、子资源定位器或子资源内找到。&@Consumes("application/json") &&@Produces("application/json")
发表评论：
TA的最新馆藏[转]&RESTful API URI 设计: 判断资源是否存在？
相关的一篇文章：RESTful API URI 设计的一些总结。 问题场景：判断一个资源（Resources）是否存在，URI 该如何设计？ 应用示例：判断 id 为 1 用户下，名称为 windows 10 的产品是否存在？ 如果这个问题出现在 MVC 项目中，我想我们一般会这样设计
22:44&&&[]
相关文章：RESTful API URI 设计的一些总结。 问题场景：删除一个资源（Resources），URI 该如何设计？ 应用示例：删除名称为 iPhone 6 的产品。 是不是感觉很简单呢？根据应用示例，我们用代码实现下： public class ProductsController
20:04&&&[]
，看文件是否存在....................
_access(&const&char&*path,&0);
-14:58&&&[]
网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备......）。 因此，必须有一种统一的机制，方便不同的前端设备与后端进行通信。这导致API构架的流行，甚至出现&API First&的设计思想。RESTful API
21:21&&&[]
RESTFul API
基于REST原则设计的API，一般称为RESTFul API，需要遵守以下这些原则。
URL描述的是一个特定资源。因此描述需要名词，不能出现动词。因为动词描述的不再是资源本身，而是行为
利用HTTP请求的动词表示对于资源操作的行为
同时，对于URL的设计
04:45&&&[]
目前互联网上充斥着大量的关于RESTful API（为方便，下文中“RESTful API ”简写为“API”）如何设计的文章，然而却没有一个”万能“的设计标准：如何鉴权？API 格式如何？你的API是否应该加入版本信息？当你开始写一个app的时候，特别是后端模型部分已经写完的时候，你
14:09&&&[]
文件是有授权的用户才能访问的，在这句前面怎样把用户名和密码写上啊？
System.IO.File.Exists(filePath)
回复讨论(解决方案)
这句话写不上，先把问题描述清楚，怎么个授权
文件只共享给了A用户，现在要写程序判断文件是否存在，如果没有权限的话用下面这句就搞定了
-20:10&&&[]
来自： /a/3103
之所以创建这个 repository，是因为我希望收集一些比较好的有关于 RESTful API 设计的参考文献。偶尔回顾，偶尔改进，大家一起来吧~
如果你有更好的私藏文章，不凡分享出来，独乐乐不如众
11:47&&&[]
Restful这个名称应该很多人都不陌生，但是我发现不少人对Restful存在或多或少的理解偏差，其中不泛比较厉害的程序员，所以有必要为Restful来“正名”。 Restful是一种软件架构风格，设计风格而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个
10:24&&&[]
Web API已经在最近几年变成重要的话题，一个干净的API设计对于后端系统是非常重要的。
　　通常我们为Web API使用RESTful设计，REST概念分离了API结构和逻辑资源，通过Http方法GET, DELETE, POST 和 PUT来操作资源。
　　下面是进行RESTful
16:02&&&[]
现有状况 发现很多RESTful API的错误代码都是用HTTP的状态码(Status Code)作为API的错误代码，公司的一些产品也是如此，如下图所示：
这种设计基本是把错误代码依次映射到HTTP的状态码上，HTTP协议中定义的状态码基本包含下面几类： 1xx Informational
10:00&&&[]
06:44&&&[]