webapi服务端 返回的状态码是_webapi 返回状态 - CSDN
精华内容
参与话题
  • 前两天一直在配置tomcat服务器,期间遇到一些返回状态码的问题。现将其总结汇总: 2XX 表示成功: 200 表示客户端的请求在服务器端被正常处理。 204 表示请求被处理成功但是没有资源返回。 206 表示客户端进行了...

    前两天一直在配置tomcat服务器,期间遇到一些返回状态码的问题。现将其总结汇总:

    2XX     表示成功:

    200    表示客户端的请求在服务器端被正常处理。

    204    表示请求被处理成功但是没有资源返回。

    206    表示客户端进行了范围请求,而服务器成功执行了get()请求。

    3XX     表示重定向:

    301    表示永久重定向。

    302    临时重定向。

    303    与302有相同的功能,都表示请求对应着另一个URI,但是303使用了get()方法。

    304    表示服务器允许请求访问资源,但没有满足条件的情况。

    4XX      表示客户端错误:

    400    请求的报文中存在语法错误。

    401    发送的请求需要HTTP的认证。

    403    请求访问资源被服务器拒绝。

    404    服务器无法找到请求的资源。

    5XX      服务器错误:

    500    服务器端在执行请求时发生错误或者是Web应用存在故障。

    503    服务器超负载或者正在停机维护。

    展开全文
  • RESTful API使用JWT做无状态的身份认证

    千次阅读 2020-06-29 18:36:38
    JWT设计RESTful架构的前后端,天然要求API是无状态的,JWT(JSON Web Token)简单易用,适合在分布式系统中做API状态的身份认证。jwt由Header、Payload、Signature三部分组成,使用 . 分割开,一个JWT形式:Header....

    JWT设计

    RESTful架构的前后端,经常会使用Token令牌做身份验证,JWT(JSON Web Token)是一种简单易用的Token标准,适合在应用中做无状态的API身份认证。

    在这里插入图片描述

    jwt由Header、Payload、Signature三部分组成,使用 . 分割开,一个JWT形式:

    Header.Payload.Signature
    

    这三部分分别对应的是加密算法、携带的用户信息、加密后的字符串(签名)。

    Jwt自带签名,能够防止伪造或篡改,但要防止token被窃取还要配合https使用。

    下面我们用Jwt开发一个前后端交互系统。

    JWT服务端

    这里使用jjwt开源库生成token:

    https://github.com/jwtk/jjwt

    创建RESTful接口

    Server端基于SpringBoot开发,提供生成token和校验token的接口:

    @PostMapping("/login")
    Back login(@RequestParam String name,
               @RequestParam String pwd);
    
    @GetMapping("/user")
    Back getUser(@RequestHeader String jwt);
    
    • 登录或注册接口:客户端提交用户名密码,服务端完成登录或注册逻辑,然后生成jwt令牌并返回给客户端

    • 用户信息接口:客户端将token放在请求头,服务端校验是否合法,然后再从MySQL中查询并返回用户信息

    • 服务端无需存储jwt令牌,通过特定的算法和密钥校验token,同时取出Payload中携带的用户ID,减少不必要的数据库查询

    • 本例中设置JWT有效期为3天,服务端每次都会自动校验token是否过期,如果过期就直接抛出异常,客户端需要重新申请token

    Token统一校验

    业务相关接口一般都需要token验证,这就应该把验证逻辑放在一个统一的切面层完成,Spring的AOP正好满足这一需要。

    这里实现Spring的拦截器HandlerInterceptor接口,在Controller方法执行之前拦截需要鉴权的请求,验证token是否合法,合法就放行,不合法则直接抛出异常拦截请求。

    public class JwtInterceptor implements HandlerInterceptor {
    
        @Override
        public boolean preHandle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o) {
            //在请求处理之前校验token
            String token = httpServletRequest.getHeader("jwt");
            return Util.verify(token);
        }
    
        @Override
        public void postHandle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o, ModelAndView modelAndView) {
    
        }
    
        @Override
        public void afterCompletion(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o, Exception e) {
    
        }
    }
    

    然后在WebMvcConfigurerAdapter中添加此拦截器,就可以实现Token统一校验了。

    服务端源码:https://github.com/yunTerry/JWT-Server

    JWT客户端

    Android客户端使用Retrofit做REST请求。

    • 登录或注册接口:提交用户名密码,服务端返回jwt令牌:

    在这里插入图片描述

    • 用户信息接口:客户端将token放在请求头,服务端校验通过即返回用户信息

    • 客户端在本地存储token以后就能免登陆

    客户端源码:https://github.com/yunTerry/JWT-Android

    JWT的缺陷

    JWT使用起来虽然简单方便,但它存在一个缺陷,即服务端无法主动注销token,如果修改秘钥会让所有token失效,代价太大,通常只是被动等待token过期失效,所以jwt在安全性上不及session,实际开发中应合理设置过期时间。

    如果要让服务端能够注销token,就要在服务端维护token状态,但这又回到session机制了。

    JWT这个缺陷决定了它更适合用在短期的token验证场景中,或者也可以结合session做长短期双重验证,弥补session的一些不足。

    展开全文
  • 设计一个良好的restful风格API

    万次阅读 2018-04-13 18:31:24
    阅读原文版本号在 RESTful API 中,API 接口应该尽量兼容之前的版本。...实际上,Web 端是部署在服务器,因此它可以很容易为了适配服务端的新的 API 接口进行版本升级,然而像 Android 端、IOS 端、PC 端等其他...

    阅读原文

    版本号

    在 RESTful API 中,API 接口应该尽量兼容之前的版本。但是,在实际业务开发场景中,可能随着业务需求的不断迭代,现有的 API 接口无法支持旧版本的适配,此时如果强制升级服务端的 API 接口将导致客户端旧有功能出现故障。实际上,Web 端是部署在服务器,因此它可以很容易为了适配服务端的新的 API 接口进行版本升级,然而像 Android 端、IOS 端、PC 端等其他客户端是运行在用户的机器上,因此当前产品很难做到适配新的服务端的 API 接口,从而出现功能故障,这种情况下,用户必须升级产品到最新的版本才能正常使用。

    为了解决这个版本不兼容问题,在设计 RESTful API 的一种实用的做法是使用版本号。一般情况下,我们会在 url 中保留版本号,并同时兼容多个版本。

    【GET】  /v1/users/{user_id}  // 版本 v1 的查询用户列表的 API 接口
    【GET】  /v2/users/{user_id}  // 版本 v2 的查询用户列表的 API 接口

    现在,我们可以不改变版本 v1 的查询用户列表的 API 接口的情况下,新增版本 v2 的查询用户列表的 API 接口以满足新的业务需求,此时,客户端的产品的新功能将请求新的服务端的 API 接口地址。虽然服务端会同时兼容多个版本,但是同时维护太多版本对于服务端而言是个不小的负担,因为服务端要维护多套代码。这种情况下,常见的做法不是维护所有的兼容版本,而是只维护最新的几个兼容版本,例如维护最新的三个兼容版本。在一段时间后,当绝大多数用户升级到较新的版本后,废弃一些使用量较少的服务端的老版本API 接口版本,并要求使用产品的非常旧的版本的用户强制升级。

    注意的是,“不改变版本 v1 的查询用户列表的 API 接口”主要指的是对于客户端的调用者而言它看起来是没有改变。而实际上,如果业务变化太大,服务端的开发人员需要对旧版本的 API 接口使用适配器模式将请求适配到新的API 接口上。

    资源路径

    RESTful API 的设计以资源为核心,每一个 URI 代表一种资源。因此,URI 不能包含动词,只能是名词。注意的是,形容词也是可以使用的,但是尽量少用。一般来说,不论资源是单个还是多个,API 的名词要以复数进行命名。此外,命名名词的时候,要使用小写、数字及下划线来区分多个单词。这样的设计是为了与 json 对象及属性的命名方案保持一致。例如,一个查询系统标签的接口可以进行如下设计。

    【GET】  /v1/tags/{tag_id} 

    同时,资源的路径应该从根到子依次如下。

    /{resources}/{resource_id}/{sub_resources}/{sub_resource_id}/{sub_resource_property}

    我们来看一个“添加用户的角色”的设计,其中“用户”是主资源,“角色”是子资源。

    【POST】  /v1/users/{user_id}/roles/{role_id} // 添加用户的角色

    有的时候,当一个资源变化难以使用标准的 RESTful API 来命名,可以考虑使用一些特殊的 actions 命名。

    /{resources}/{resource_id}/actions/{action}

    举个例子,“密码修改”这个接口的命名很难完全使用名词来构建路径,此时可以引入 action 命名。

    【PUT】  /v1/users/{user_id}/password/actions/modify // 密码修改

    请求方式

    可以通过 GET、 POST、 PUT、 PATCH、 DELETE 等方式对服务端的资源进行操作。其中,GET 用于查询资源,POST 用于创建资源,PUT 用于更新服务端的资源的全部信息,PATCH 用于更新服务端的资源的部分信息,DELETE 用于删除服务端的资源。

    这里,笔者使用“用户”的案例进行回顾通过 GET、 POST、 PUT、 PATCH、 DELETE 等方式对服务端的资源进行操作。

    【GET】          /users                # 查询用户信息列表
    【GET】          /users/1001           # 查看某个用户信息
    【POST】         /users                # 新建用户信息
    【PUT】          /users/1001           # 更新用户信息(全部字段)
    【PATCH】        /users/1001           # 更新用户信息(部分字段)
    【DELETE】       /users/1001           # 删除用户信息

    查询参数

    RESTful API 接口应该提供参数,过滤返回结果。其中,offset 指定返回记录的开始位置。一般情况下,它会结合 limit 来做分页的查询,这里 limit 指定返回记录的数量。

    【GET】  /{version}/{resources}/{resource_id}?offset=0&limit=20

    同时,orderby 可以用来排序,但仅支持单个字符的排序,如果存在多个字段排序,需要业务中扩展其他参数进行支持。

    【GET】  /{version}/{resources}/{resource_id}?orderby={field} [asc|desc]

    为了更好地选择是否支持查询总数,我们可以使用 count 字段,count 表示返回数据是否包含总条数,它的默认值为 false。

    【GET】  /{version}/{resources}/{resource_id}?count=[true|false]

    上面介绍的 offset、 limit、 orderby 是一些公共参数。此外,业务场景中还存在许多个性化的参数。我们来看一个例子。

    【GET】  /v1/categorys/{category_id}/apps/{app_id}?enable=[1|0]&os_type={field}&device_ids={field,field,…}

    注意的是,不要过度设计,只返回用户需要的查询参数。此外,需要考虑是否对查询参数创建数据库索引以提高查询性能。

    状态码

    使用适合的状态码很重要,而不应该全部都返回状态码 200,或者随便乱使用。这里,列举笔者在实际开发过程中常用的一些状态码,以供参考。

    状态码描述
    200请求成功
    201创建成功
    400错误的请求
    401未验证
    403被拒绝
    404无法找到
    409资源冲突
    500服务器内部错误

    异常响应

    当 RESTful API 接口出现非 2xx 的 HTTP 错误码响应时,采用全局的异常结构响应信息。

    HTTP/1.1 400 Bad Request
    Content-Type: application/json
    {
        "code": "INVALID_ARGUMENT",
        "message": "{error message}",
        "cause": "{cause message}",
        "request_id": "01234567-89ab-cdef-0123-456789abcdef",
        "host_id": "{server identity}",
        "server_time": "2014-01-01T12:00:00Z"
    }

    请求参数

    在设计服务端的 RESTful API 的时候,我们还需要对请求参数进行限制说明。例如一个支持批量查询的接口,我们要考虑最大支持查询的数量。

    【GET】     /v1/users/batch?user_ids=1001,1002      // 批量查询用户信息
    参数说明
    - user_ids: 用户ID串,最多允许 20 个。

    此外,在设计新增或修改接口时,我们还需要在文档中明确告诉调用者哪些参数是必填项,哪些是选填项,以及它们的边界值的限制。

    【POST】     /v1/users                             // 创建用户信息
    请求内容
    {
        "username": "lgz",                 // 必填, 用户名称, max 10
        "realname": "梁桂钊",               // 必填, 用户名称, max 10
        "password": "123456",              // 必填, 用户密码, max 32
        "email": "lianggzone@163.com",     // 选填, 电子邮箱, max 32
        "weixin": "LiangGzone",            // 选填,微信账号, max 32
        "sex": 1                           // 必填, 用户性别[1-男 2-女 99-未知]
    }

    响应参数

    针对不同操作,服务端向用户返回的结果应该符合以下规范。

    【GET】     /{version}/{resources}/{resource_id}      // 返回单个资源对象
    【GET】     /{version}/{resources}                    // 返回资源对象的列表
    【POST】    /{version}/{resources}                    // 返回新生成的资源对象
    【PUT】     /{version}/{resources}/{resource_id}      // 返回完整的资源对象
    【PATCH】   /{version}/{resources}/{resource_id}      // 返回完整的资源对象
    【DELETE】  /{version}/{resources}/{resource_id}      // 状态码 200,返回完整的资源对象。
                                                          // 状态码 204,返回一个空文档

    如果是单条数据,则返回一个对象的 JSON 字符串。

    HTTP/1.1 200 OK
    {
        "id" : "01234567-89ab-cdef-0123-456789abcdef",
        "name" : "example",
        "created_time": 1496676420000,
        "updated_time": 1496676420000,
        ...
    }

    如果是列表数据,则返回一个封装的结构体。

    HTTP/1.1 200 OK
    {
        "count":100,
        "items":[
            {
                "id" : "01234567-89ab-cdef-0123-456789abcdef",
                "name" : "example",
                "created_time": 1496676420000,
                "updated_time": 1496676420000,
                ...
            },
            ...
        ]
    }

    一个完整的案例

    最后,我们使用一个完整的案例将前面介绍的知识整合起来。这里,使用“获取用户列表”的案例。

    【GET】     /v1/users?[&keyword=xxx][&enable=1][&offset=0][&limit=20] 获取用户列表
    功能说明:获取用户列表
    请求方式:GET
    参数说明
    - keyword: 模糊查找的关键字。[选填]
    - enable: 启用状态[1-启用 2-禁用]。[选填]
    - offset: 获取位置偏移,从 0 开始。[选填]
    - limit: 每次获取返回的条数,缺省为 20 条,最大不超过 100。 [选填]
    响应内容
    HTTP/1.1 200 OK
    {
        "count":100,
        "items":[
            {
                "id" : "01234567-89ab-cdef-0123-456789abcdef",
                "name" : "example",
                "created_time": 1496676420000,
                "updated_time": 1496676420000,
                ...
            },
            ...
        ]
    }
    失败响应
    HTTP/1.1 403 UC/AUTH_DENIED
    Content-Type: application/json
    {
        "code": "INVALID_ARGUMENT",
        "message": "{error message}",
        "cause": "{cause message}",
        "request_id": "01234567-89ab-cdef-0123-456789abcdef",
        "host_id": "{server identity}",
        "server_time": "2014-01-01T12:00:00Z"
    }
    错误代码
    - 403 UC/AUTH_DENIED    授权受限
    展开全文
  • 概念 本质:一种软件架构风格 核心:面向资源设计的API 解决问题: ...所有的操作都是无状态的(本次操作、下次操作、上次操作之间无关系) 资源:网络上的一个实体、具体信息。 HTTP RESTful 与...

    概念

    本质:一种软件架构风格
    核心:面向资源设计的API

    解决问题:

    • 降低开发的复杂性
    • 提高系统的可伸缩性

    例如:设计一套API,为多个终端服务。

    设计概念和准则

    • 网络上的所有事物都可以被抽象为资源
    • 每一个资源都有唯一的资源标识,对资源的操作不会改变这些标识
    • 所有的操作都是无状态的(本次操作、下次操作、上次操作之间无关系)

    资源:网络上的一个实体、具体信息。

    HTTP

    RESTful 与HTTP协议操作无关,但是它是按照HTTP的思想进行设计的,所以有必要知道HTTP

    参考官方文档:https://tools.ietf.org/html/rfc2616

    schema://host[:port]/path[?query-string][#author]

    • shceme 指定低层使用的协议(如http,https,ftp)
    • host 服务器的IP地址或域名
    • port 服务器端口,默认为80
    • path 访问资源的路径
    • query-string 发送给http服务器的数据,常用于对资源进行筛选操作
    • anchor 锚,链接

    请求

    • 格式:请求行、消息报头、请求正文

    请求行格式: Method Request-URI HTTP-Version CRLF

    如: GET/HTTP.1.1 CRLF

    • 请求方法

    GET : 请求获取Request-URI 所标识的资源
    POST :在Request-URI 所标识的资源后附加新的数据
    HEAD : 请求获取由Request-URI所标识的资源的响应消息报头

    PUT : 请求服务器存储一个资源,并用Request-URI作为其标识
    DELETE :请求服务器删除Request-URI所标识的资源
    OPTIONS : 请求查询服务器性能,或者查询与资源相关的选项和需求

    对资源的操作:创建、编辑、请求、删除

    响应

    • 格式:状态行、消息报头、响应正文

    状态行格式:HTTP-Version Status-Code Reason-Phrase CRLF

    如: HTTP/1.1 200 OK

    • 常用响应状态码(在RESTful 中有重要应用)

    200 OK //客户端请求成功

    400 Bad Request //客户端请求有语法错误,不能被服务器所理解

    401 Unanthorized //服务器收到请求,但是服务器拒绝提供服务

    404 Not Found //请求资源不存在

    500 Internal Serval Error //服务器发生不可预期的错误

    503 Server Unavailable // 服务器当前不能处理客户端的请求

    RESTful 架构与其他架构的区别

    API 的开发方式不止一种,另一种比较流行的开发方式是SOAP WebService。

    SOAP WebService

    WebService 是一种跨编程语言和跨操作系统平台的远程调用技术。其通过HTTP协议发送请求和接收结果时采用XML格式封装,并增加了一些特定的HTTP消息头,这些特定的HTTP消息头和XML内容格式就是SOAP协议。

    对比

    • 效率与易用性:SOAP由于各种需求不断扩充其本身协议的内容,导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。而RESTful API 在请求方法、资源、地址都进行了规范,其最大限度的利用了HTTP最初的应用协议的设计理念。
    • 安全性:RESTful 对于资源型服务器接口比较适合,适合对于效率要求很高,但是对于安全要求不高的场景。SOAP 的成熟性可以给需要提供给多开发语言的,对于安全性的要求较高的接口设计带来便利,你可以在客户端和服务端应用证书进行安全措施。所以关键看应用场景。

    使用RESTful

    设计RESTful API

    • 资源路径(URI):RESTful的核心是面向资源,如何规划资源路径很重要

    • HTTP动词(请求方式):如get,post,delete,put

    • 过滤信息:例如获取资源列表时有分页操作/查询操作,这时要合理分配过滤信息,过滤信息设置太多,有可能会违反RESTful API 关于URI方面的限定。

    • 状态码:当客户端发送一个请求时,服务端应当响应什么状态码

    • 错误处理:如当发现客户端传入的参数有问题时,该返回什么样的状态信息。

    • 返回结果:如POST资源的时候,需要返回一个资源实例;GET资源列表时,需要返回一个资源数组;

    资源路径

    在RESTful架构中,每个网址代表一个资源,所以网址中不能有动词,只能有名词。一般而言,API中的名词应该使用复数。例如,使用users反映用户资源的URI,而不是使用user。

    例如:有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,那么它的资源路径应设计成如下样子。

    https://api.example.com/v1/zoos  //动物园资源。使用https协议头;加入v1版本号,因为以后可能会更改api。版本号的加入有两种做法,一种是加入到地址中,另一种是加入到HTTP请求头中;zoos复数
    
    https://api.example.com/v1/animals //动物资源
    
    https://api.example.com/v1/employees //雇员资源
    
    

    HTTP动词

    对资源的操作有创建、读取、更新、删除(CURD),由HTTP动词表示。

    • GET : 从服务器去除资源
    • POST :在服务器新建一个资源
    • PUT:在服务器更新资源(客户端提供改变后的完整资源,服务端返回完整的更新字段)
    • PATCH:在服务器更新资源(客户端提供改变的属性,服务端返回只发生了更新的字段)
    • DELETE:从服务器删除资源

    例如:

    POST/zoos : 新建一个动物园
    GET/zoos/ID : 获取某个指定动物园的信息
    PUT/zoos/ID : 更新某个指定动物园的信息
    DELETE/zoos/ID : 删除某个动物园
    

    过滤信息

    如果记录数量过多,服务器不可能都将它们返回给用户。这时就需要进行筛选。筛选时,API应该提供一个参数,过滤一下返回的结果。

    例如:

    ?offset = 10 :指定返回记录的开始位置
    ?page = 2&per_page = 100 :指定第几页,以及每页的记录数
    ?sortby = name&order = asc :指定返回结果排序,以及排序顺序
    ?animal_type_id = 1 :指定筛选条件
    

    状态码

    服务器向用户返回的状态码和提示信息,使用标准的HTTP状态码

    • 200 OK 服务器成功返回用户请求的数据
    • 201 CREATED 新建或修改数据成功
    • 204 NO CONTENT 删除数据成功
    • 400 BAD REQUEST 用户发出的请求有错误
    • 401 Unauthorized 表示用户没有认证,无法进行当前操作
    • 403 Forbidden 表示用户的访问是被禁止的
    • 422 Unprocesable Entity 当创建一个对象时,发生一个验证错误。例如创建用户资源时需要用户名、密码,而前端只提供用户名字段,那么就要返回一个422 状态码,并返回错误信息:”密码不能为空“
    • 500 INTERNAL SERVER ERROR 服务器内部错误,此时服务端无法处理任何请求。

    错误处理

    如果状态码是4xx或5xx,就应该向用户返回出错信息。一般而言,返回的信息中将error作为键名,出错信息作为键值即可,例如:

    {
      "error":"参数错误"
    }
    

    返回结果

    针对不同操作(如GET,POST),服务器向用户返回的结果应该符合以下规范:

    • GET/collections: 返回资源对象的列表(数组)
    • GET/collections/identity : 读取资源时,传入标识符(identity),服务端返回标识符指定的单个资源对象
    • POST/collections : 返回新生成的资源对象
    • PUT/collections/identity : 返回完整的资源对象
    • PATCH/collections/identity : 返回被修改的属性
    • DELETE/collections/identity : 返回一个204状态码和空响应体

    DHC Client 用于测试API

    • 安装DHC 谷歌浏览器插件:

    名为: 基于REST的Web服务客户端
    先下载: http://chromecj.com/web-development/2015-03/401.html

    或在谷歌商店 :https://chrome.google.com/webstore/detail/rest-web-service-client/ecjfcmddigpdlehfhdnnnhfgihkmejin?hl=zh-CN

    然后安装。

    在这里插入图片描述

    本地开发环境搭建

    • 安装PHP环境集成包 XAMPP 或 upupw

    • 添加虚拟主机,以及取消跨站目录限制 httpd-vhosts.conf文件中 找到添加的域名,将php_admin_value xxx这句开头加入井号进行注释
      在这里插入图片描述

    • 添加虚拟主机的本地hosts解析 : 更改本地hosts文件,添加 127.0.0.1 api.com本地域名解析
      在这里插入图片描述

    确认设计要素

    项目需求

    • 用户登录、注册
    • 文章发表、编辑、管理、列表

    确认设计要素

    • 资源路径: /users , /articles
    • HTTP动词: GET,POST,DELETE,PUT
    • 过滤信息: 文章分页筛选
    • 状态码: 200,404,422,403…
    • 错误处理:输出JSON格式错误信息
    • 返回结果:输出JSON数组或JSON对象

    数据库设计

    在数据库中新建2张表:

    • 用户表: ID、用户名、密码、注册时间
    • 文章表: 文章ID、标题、内容、发表时间、用户ID

    添加.htaccess Apache重写文件

    在这里插入图片描述

    之后就可以在IDE中进行相应的开发编码工作。

    当然,处理RESTful API设计思想,还有最近流行的GraphQL,它是一种API查询语言,其将所见即所得的思想引入,能帮助提升开发的体验与应用的性能。(参考:http://graphql.cn/ )

    参考

    展开全文
  • c# WebApi之接口返回类型详解

    万次阅读 2017-11-27 14:52:31
    WebApi相关文章: C# 搭建一个简单的Web API项目 ...c# WebApi之接口返回类型详解 Webapi的接口返回值主要有四种类型 void无返回值 IHttpActionResult HttpResponseMessage 自定义类型void无返回值大家都知道voi
  • 网络基础10 Restful API设计规范

    万次阅读 2020-06-16 14:21:44
    Restful API设计规范总结
  • 采用http传输json进行服务端接口与客户端对接,以及restful风格实现
  • Web返回结果和HTTP状态码详解

    千次阅读 2017-04-07 21:25:23
    状态码类别 状态码 类别 原因短语 1XX Informational(信息性状态码) 接受的请求正在处理 2XX Success(成功状态码) 请求正常处理完毕 3XX Redirection(重定向状态码) 需要进行附加操作以完成请求 4...
  • 1.什么是RESTREST全称是Representational State Transfer,表述状态转移的意思。它是在Roy Fielding博士论文首次提出。REST本身没有创造新的技术、组件或服务,它的理念就是在现有的技术之上,更好的使用现有的 web...
  • HTTP报文

    万次阅读 热门讨论 2012-07-15 08:45:52
    学习Web开发不好好学习HTTP报文,将会“打拳不练功,到老一场空”,你花在犯迷糊上的时间比你沉下心来学习HTTP的时间肯定会多很多。 HTTP请求报文解剖  HTTP请求报文由3部分组成(请求行+请求头+请求体): ...
  • HTTP请求行、请求头、请求体详解

    万次阅读 多人点赞 2017-03-30 19:09:22
    HTTP请求
  • HTTP报文详解

    万次阅读 多人点赞 2012-09-24 17:03:58
    学习Web开发不好好学习HTTP报文,将会“打拳不练功,到老一场空”,你花在犯迷糊上的时间比你沉下心来学习HTTP的时间肯定会多很多。 HTTP请求报文解剖  HTTP请求报文由3部分组成(请求行+请求头+请求体): ...
  • WebSocket 实战

    万次阅读 2015-07-18 23:05:16
    本文介绍了 HTML5 WebSocket 的由来,运作机制及客户端和服务端API 实现,重点介绍服务端(基于 Tomcat7)及客户端(基于浏览器原生 HTML5 API)实现的详细步骤;并通过实际客户案例描述了客户端如何在 WebSocket...
  • web安全认证机制知多少

    万次阅读 2017-12-08 15:26:19
    如今web服务随处可见,成千上万的web程序被部署到公网上供用户访问,有些系统只针对指定用户开放,属于安全级别较高的web应用,他们需要有一种认证机制以保护系统资源的安全,本文将探讨五种常用的认证机制及优缺点...
  • 面试官:你连RESTful都不知道我怎么敢要你?

    万次阅读 多人点赞 2020-03-05 21:34:09
    干货,2019 RESTful最贱实践
  • 前后端分离:WebAPI+Vue开发——远程数据请求axios 前后端分离:WebAPI+Vue开发——跨域设置 前后端分离:WebAPI+Vue开发——身份认证 存储用户身份可以用Cache内存或者Redis,本文实现用的是Redis。 1、在登录...
  • ...上一篇我们介绍了如何使用vue resource处理HTTP请求,结合服务端的REST API,就能够很容易...这个应用始终遗留了一个问题,Web App在访问REST API时,没有经过任何认证,这使得服务端的REST API是不安全的,只
  • 服务端接口编写,我用的是springmvc,服务端接口其实和平时web开发一样,就是返回出json就好了,还有就是接受数据也是json,方法如下: @Controller @RequestMapping("/user") pub...
  • RESTful API 中的错误处理

    千次阅读 2018-04-08 09:00:13
    构建 Web 服务时,我们会使用 RESTful API 来实现组件间的通信,特别是在现今前后端分离的技术背景下。REST 是一种基于 HTTP 协议的通信方式,它简单、基于文本、且在各种语言、浏览器及客户端软件中能得到很好的...
  • 自己最近无聊在搞web api 安全认证这块,看到了这两篇文章,感觉写的非常到位,这一篇是对上一篇 WebApi安全性 使用TOKEN+签名验证 进行的一些讲解! 本篇博文中的所有代码均来自上述链接,如果你觉得有帮助,请...
1 2 3 4 5 ... 20
收藏数 28,505
精华内容 11,402
关键字:

webapi服务端 返回的状态码是