RESTful

laravel的RESTful实现:RESTful资源控制器-通过laravel 学习RESTful

RESTful 资源控制器

资源控制器让你可以轻松地创建与资源相关的 RESTful 控制器.Laravel 的资源路由将典型的「CURD (增删改查)」路由分配给具有单行代码的控制器。例如,你希望创建一个控制器来处理保存 "照片" 应用的所有 HTTP 请求。使用 Artisan 命令 make:controller ,我们可以快速创建这样一个控制器:

php artisan make:controller PhotoController --resource

                

RESTful API设计 最佳实践。

设计HTTP和RESTful API可能很棘手,因为没有官方和强制标准。基本上,有许多方法可以实现API,但其中一些已在实践中得到证实,并且已被widley采用。这篇文章介绍了构建HTTP和RESTful API的最佳实践。我们将讨论URL结构,HTTP方法,创建和更新资源,设计关系,有效负载格式,分页,版本控制等等。

RESTful API设计。 坚果壳中的最佳实践。

更新2018年

我完全重写了这篇文章。我重新访问并扩展了现有的部分并添加了许多新的部分:HTTP方法和状态代码的新概述,PATCH,清除PUT和POST的语义,data字段,设计关系,REST与RPC风格的API,可演化性,版本控制方法,基于键集分页,JSON:API,JSON:API启发的有效负载格式。…

        

API设计指南

大多数现代Web应用程序都公开了客户端可用于与应用程序交互的API。精心设计的Web API应旨在支持:

  • 平台独立性无论API如何在内部实施,任何客户端都应该能够调用API。这需要使用标准协议,并且具有客户端和Web服务可以就要交换的数据格式达成一致的机制。
  • 服务发展Web API应该能够独立于客户端应用程序进化和添加功能。随着API的发展,现有的客户端应用程序应该继续运行而无需修改。应该可以发现所有功能,以便客户端应用程序可以完全使用它。

本指南介绍了在设计Web API时应考虑的问题。

REST简介

2000年,Roy Fielding提出了Representational State Transfer(REST)作为设计Web服务的架构方法。REST是一种用于构建基于超媒体的分布式系统的架构风格。REST独立于任何底层协议,不一定与HTTP绑定。但是,大多数常见的REST实现都使用HTTP作为应用程序协议,本指南重点介绍如何为HTTP设计REST API。

REST over HTTP的主要优点是它使用开放标准,并且不会将API或客户端应用程序的实现绑定到任何特定实现。例如,REST Web服务可以用ASP.NET编写,客户端应用程序可以使用任何可以生成HTTP请求和解析HTTP响应的语言或工具集。

以下是使用HTTP的RESTful API的一些主要设计原则:

  • REST API是围绕资源设计的,资源是客户端可以访问的任何类型的对象,数据或服务。
  • 资源具有标识符,该
        

RESTful API 最佳实践

RESTful 是目前最流行的 API 设计规范,用于 Web 数据接口的设计。

它的大原则容易把握,但是细节不容易做对。本文总结 RESTful 的设计细节,介绍如何设计出易于理解和使用的 API。

一、URL 设计

1.1 动词 + 宾语

RESTful 的核心思想就是,客户端发出的数据操作指令都是"动词 + 宾语"的结构。比如,GET /articles这个命令,GET是动词,/articles是宾语。

动词通常就是五种 HTTP 方法,对应 CRUD 操作。

  • GET:读取(Read)
  • POST:新建(Create)
  • PUT:更新(Update)
  • PATCH:更新(Update),通常是部分更新
  • DELETE:删除(Delete)

根据 HTTP 规范,动词一律大写。

        

人人都是 API 设计师:我对 RESTful API、GraphQL、RPC API 的思考

有一段时间没怎么写文章了,今天提笔写一篇自己对 API 设计的思考。首先,为什么写这个话题呢?其一,我阅读了《阿里研究员谷朴:API 设计最佳实践的思考》一文后受益良多,前两天并转载了这篇文章也引发了广大读者的兴趣,我觉得我应该把我自己的思考整理成文与大家一起分享与碰撞。其二,我觉得我针对这个话题,可以半个小时之内搞定,争取在 1 点前关灯睡觉,哈哈。

现在,我们来一起探讨 API 的设计之道。我会抛出几个观点,欢迎探讨。

一、定义好的规范,已经成功了一大半

通常情况下,规范就是大家约定俗成的标准,如果大家都遵守这套标准,那么自然沟通成本大大降低。例如,大家都希望从阿里的规范上面学习,在自己的业务中也定义几个领域模型:VO、BO、DO、DTO。其中,DO(Data Object)与数据库表结构一一对应,通过 DAO 层向上传输数据源对象。 而 DTO(Data Transfer Object)是远程调用对象,它是 RPC 服务提供的领域模型。对于 BO(Business Object),它是业务逻辑层封装业务逻辑的对象,一般情况下,它是聚合了多个数据源的复合对象。那么,VO(View Object) 通常是请求处理层传输的对象,它通过 Spring 框架的转换后,往往是一个 JSON 对象。…

            

REST真的完全适合微服务架构吗?

【编者的话】作者根据自己的微服务经验,提出REST并不是微服务的唯一通信机制,从而介绍了微服务的几种通信机制,包括REST、管道以及基于异步消息传递。同时,作者提出了在不同的场景下可以使用不同的通信机制。

在我接触微服务的这段时间,大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此,你可能理所当然地认为REST就是微服务的一种标准,并且是设计与实现微服务系统一种方式。然而,并非如此。…

        

RESTful API 设计最佳实践

来源:http://www.oschina.net/translate/best-practices-for-a-pragmatic-restful-api

数据模型已经稳定,接下来你可能需要为web(网站)应用创建一个公开的API(应用程序编程接口)。需要认识到这样一个问题:一旦API发布后,就很难对它做很大的改动并且保持像先前一样的正确性。现在,网络上有很多关于API设计的思路。但是在全部案例中没有一种被广泛采纳的标准,有很多的选择:你接受什么样的格式?如何认证?API应该被版本化吗?

在为SupportFu(一个轻量级的Zendesk替换实现)设计API时,对于这些问题我尽量得出一些务实的答案。我的目标是设计这样一个API,它容易使用和采纳,足够灵活去为我们用户接口去埋单。…

    

理解本真的REST架构风格

本文是“深入探索REST”专栏系列深度内容中的第二篇,它将带您领略REST架构的起源、与Web的关系、REST架构的本质及特性,以及REST架构与其他架构风格之间的比较。

引子

在移动互联网、云计算迅猛发展的今天,作为一名Web开发者,如果您还没听说过“REST”这个buzzword,显然已经落伍了。夸张点说,甚至“出了门都不好意思跟别人打招呼”。尽管如此,对于REST这个泊来品的理解,大多数人(包括一些资深的架构师)仍然停留在“盲人摸象”的阶段。常常听到各种各样关于REST的说法,例如:有人说:“我们这套新的API决定不用Web Service(SOAP+WSDL),而是直接使用HTTP+JSON,也就是用RESTful的方式来开发。” 不用SOAP,甚至也不用XML,就自动变成了RESTful了。还有人认为:REST与传统的Web Service其实没有本质区别,只是对于URI的构造方式提出了更多要求,而这些要求Web Service完全都可以实现。潜台词是:既生瑜,何生亮。Web Service已经足够好了,干嘛还要再折腾什么REST。这些对于REST的不同说法,果真如此吗?REST究竟是什么?是一种新的技术、一种新的架构、还是一种新的规范?

对于这些问题笔者先不解答,为了深入理解REST是什么,我们需要回顾一下Web发展的最初年代,从源头上讲讲REST是怎么得来的。…