深入理解restfulAPI和 Oauth2.0(精简版)

一、restfulAPI

1、解释:

restfulAPI协议,我们也可以说是一套API接口编写风格。

它被现在很多企业所认可和默认,是一套成俗的API接口编写方案。

2、restfulAPI之资源

例一:

https://www.xifl.com/users/1  

在PHP中,我们对数据表操作,我们会在我们的项目中构建一个model,通过控制器对model来实现基本的增删改查,并且通过视图来渲染我们获取的数据。

那么,在restfulAPI中,我们通常用全球资源定位符(URL)来表示模型数据。

简单说:资源表示模型数据。

在restfulAPI风格中,URI我们一般用复数形式,来表示模型数据的集合,例如/users , 而后面的/1 来表示数据的条数。

那么问题来了,为了统一让不同的客户端或服务商用我的接口。接口格式是统一了,怎么才能实现对资源的增删该查呢?

在http1.0或http1.1中,访问资源我们可以有不同的访问的动作。

如:

GET
POST
PUT / PATCH
DELETE
HEAD
OPTIONS

GET 我们一般用来获取资源数据。

POST 我们用来向服务器提交处理数据。

PUT / PATCH 我们用来修改资源数据。

DELETE 我们用来删除资源数据

HEAD 我们用来获取method头部信息。

OPTIONS 我们用来获取当前服务商都允许那些访问动作。

例二:

获取id为1的数据:

            $http({
                url: ‘https://www.xifl.com/users/1‘,
                method: ‘GET‘,
            }).success(function (result) {
           //console.log()
            }).error(function (errors) {
          //console.log()
            });
        };

例三:

删除id为1的数据

   $http({
                url: ‘https://www.xifl.com/users/1‘,
                method: ‘DELETE‘,
            }).success(function (result) {
           //console.log()
            }).error(function (errors) {
          //console.log()
            });
        };

那么来总结一下:

1、在restfulAPI中,我们通过统一的URL(全球资源定位符)来表示模型数据。

2、在restfulAPI中,我们通过http下不同的访问动作来实现对资源的常规操作。(增、删、改、查)

二、Oauth2.0

时间关系,待续。。。。。。0.0

原文地址:https://www.cnblogs.com/hellow-world/p/9533458.html

时间: 2024-10-08 13:47:35

深入理解restfulAPI和 Oauth2.0(精简版)的相关文章

心愿:做一个精简版MFC

我觉得自己有能力看懂MFC的C++代码和总体流程,但是由于MFC混杂了太多的东西,比如OLE等等不必要的东西,又做了无数的ASSERT判断,影响整体流程的理解.因此我要做一个精简版的MFC,而且能用它做开发,就是用现有的VC++小程序编译.仍可照样运行.这么做的原因是,希望把MFC的所有思想融为自己身体的一部分,能在主流OS上的开发应用的时候如臂使指. 一般情况下,不会改动它的语句,但有必要的话,也会改动,看情况-

OAuth2.0的理解&基础

此文章是复制黏贴网上文章的,主要做自己备用着看(也加了自己的一点见解),喜欢的读者也可以看. OAuth是一个关于授权(authorization)的开放网络标准,在全世界得到广泛应用,目前的版本是2.0版. 1. 应用场景 为了理解OAuth的适用场合,让我举一个假设的例子. 有一个"云冲印"的网站,可以将用户储存在Google的照片,冲印出来.用户为了使用该服务,必须让"云冲印"读取自己储存在Google上的照片. 问题是只有得到用户的授权,Google才会同意

深入理解OAuth2.0协议

1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备.这里就体现了一种简单的"开放授权"思想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如

(转)帮你深入理解OAuth2.0协议

1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备.这里就体现了一种简单的"开放授权"思想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如

深入理解OAuth2.0

1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备.这里就体现了一种简单的“开放授权”思想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如启动发动机

帮你深入理解OAuth2.0协议

原文地址: http://blog.csdn.net/seccloud/article/details/8192707 1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题.豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无

问题:OAuth2.0;结果:帮你深入理解OAuth2.0协议

1. 引言 如果你开车去酒店赴宴,你经常会苦于找不到停车位而耽误很多时间.是否有好办法可以避免这个问题呢?有的,听说有一些豪车的车主就不担心这个问题. 豪车一般配备两种钥匙:主钥匙和泊车钥匙.当你到酒店后,只需要将泊车钥匙交给服务生,停车的事情就由服务生去处理.与主钥匙相比,这种泊车钥匙的使用功 能是受限制的:它只能启动发动机并让车行驶一段有限的距离,可以锁车,但无法打开后备箱,无法使用车内其他设备.这里就体现了一种简单的“开放授权”思 想:通过一把泊车钥匙,车主便能将汽车的部分使用功能(如启动

程序员的自我救赎---3.1:理解Oauth2.0

<前言> (一) Winner2.0 框架基础分析 (二)PLSQL报表系统 (三)SSO单点登录 (四) 短信中心与消息中心 (五)钱包系统 (六)GPU支付中心 (七)权限系统 (八)监控系统 (九)会员中心 (十) APP版本控制系统 (十一)Winner前端框架与RPC接口规范讲解 (十二)上层应用案例 (十三)总结 <理解Oauth2.0> 关于SSO分两个篇章来讲,先讲讲Oauth2.0,之前还特地百度了一下Oauth怎么读,我们每次交流的时候都直接读字母O·A·U·T

Spring Security实现OAuth2.0授权服务 - 进阶版

<Spring Security实现OAuth2.0授权服务 - 基础版>介绍了如何使用Spring Security实现OAuth2.0授权和资源保护,但是使用的都是Spring Security默认的登录页.授权页,client和token信息也是保存在内存中的. 本文将介绍如何在Spring Security OAuth项目中自定义登录页面.自定义授权页面.数据库配置client信息.数据库保存授权码和token令牌. 一.引入依赖 需要在基础版之上引入thymeleaf.JDBC.my