通用HTTP身份验证有几种身份验证模式,每种模式在安全强度不同,在客户机或服务器软件中的可用性方面可能有所不同。最常见的认证方案是“基本”认证方案,下面将详细介绍它。参考:https://javascript.net.cn/article?id=628IANA维护着一个认证方案列表,但是主机服务也提供了其他的认证方案,比如Amazon AWS。常见的认证方案包括:BasicSee RFC 7617, base64-encoded credentials. More information below.https://tools.ietf.org/html/rfc7617BearerSee RF
今天,写篇文章介绍一下 RESTful API 中的动词覆盖吧。在开发各种小程序的时候,总是会遇到不能正常支持 HTTP 请求的平台,比如支付宝小程序只支持 GET 和 POST 请求,这时候充分利用 HTTP 请求方法的 RESTful API 就会遇到问题,不支持 PUT, PATCH, DELETE 请求,该怎么办呢?嗯,使用动词覆盖。什么是动词覆盖我最初遇到不支持全部 HTTP 请求的时候,解决方案是修改 API 路径,比如 DELETE /user/:id 时,我的方案是 POST /user/:id/delete。后来看了阮一峰的《RESTful API 最佳实践实践 》,才明白有
在实际资源操作中,总会有一些不符合 CRUD(Create-Read-Update-Delete) 的情况,一般有几种处理方法。1. 使用 POST 为需要的动作增加一个 endpoint,使用 POST 来执行动作,比如: POST /resend 重新发送邮件。2. 增加控制参数 添加动作相关的参数,通过修改参数来控制动作。比如一个博客网站,会有把写好的文章“发布”的功能,可以用上面的 POST /articles/{:id}/publish 方法,也可以在文章中增加 published:boolean 字段,发布的时候就是更新该字段 PUT /articles/{:id}?publish
首先要明确一点:REST 实际上只是一种设计风格,它并不是标准。(所以你可以看到网上一大堆的各种最佳实践,设计指南,但是没有人说设计标准)。 说说几个重要的概念: 1、REST 是面向资源的,这个概念非常重要,而资源是通过 URI 进行暴露。URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关,操作是通过 HTTP动词来体现,所以REST 通过 URI 暴露资源时,会强调不要在 URI 中出现动词。比如:左边是错误的设计,而右边是正确的。GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗
GET /rest