restful

一般基于REST API 安全设计常用方式有： HTTP Basic Basic admin:admin Basic YWRtaW46YWRtaW4= Authorization: Basic YWRtaW46YWRtaW4= 由于HTTP协议是无状态的，所有每次请求都得带上身份信息，基于Http basic验证就是简单的将用户名和密码base64编码放到header中，一般需要HTTPS,安全性较低，实现的方式可以基于代码实现也可以基于web容器配置apache,nginx等web服务器即可实现。 HTTP Digest 摘要认证 digest authentication,服务器端以nonce进行质询，客户端以用户名，密码，nonce，HTTP方法，请求的URI等信息为基础产生的response信息进行认证的方式。 ※ 不包含密码的明文传递 摘要认证步骤： 1. 客户端访问一个受http摘要认证保护的资源。 2. 服务器返回401状态以及nonce等信息，要求客户端进行认证。 HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque=

我正在寻找一种合理的方式将搜索表示为RESTful URL。 设置：我有两个模型，汽车和车库，汽车可以在车库。 所以我的网址看起来像： /car/xxxx xxx == car id returns car with given id /garage/yyy yyy = garage id returns garage with given id 汽车可以独立存在（因此/汽车），也可以存在于车库中。 例如，在给定车库中代表所有车辆的正确方法是什么？ 就像是： /garage/yyy/cars ? 车库yyy和zzz中的汽车联盟怎么样？ 什么是代表搜索具有某些属性的汽车的正确方法？ 说：给我看看所有带4扇门的蓝色轿车： /car/search?color=blue&type=sedan&doors=4 或者它应该是/汽车而不是？ 使用“搜索”似乎不合适 - 什么是更好的方式/术语？ 应该只是： /cars/?color=blue&type=sedan&doors=4 搜索参数应该是PATHINFO还是QUERYSTRING的一部分？ 简而言之，我正在寻找跨模型REST网址设计和搜索的指导。 [更新]我喜欢贾斯汀的答案，但他没有涉及多字段搜索案例： /cars/color:blue/type:sedan/doors:4 或类似的东西。 我们怎么样 /cars/color/blue

说到想写这篇博客 这几天来，因为疫情在家 闲来无事在网上了解了了几款开源私有网盘的应用，比如nextcloud和seafile 在实际部署的过程中发现nextcloud虽然界面美观，但是整体是由php开发的，而且文档还是英文，不对我胃口（我在网上找开源网盘也是想自己动手开发出一需要云存储数据的应用，不过本人以vue+spring开发为主，php啃不动撒） 对比nextcloud，seafile是由国人团队开发，还提供相对nextcloud更为全面的API接口。 seafile API文档地址 说回重点 小生在seafile的文档中看到了两个比较陌生的词WebDAV和FUSE，后者是一种虚拟的文件系统技术，可以在文件系统上挂载一个虚拟目录。如果结合一些Web API可实现 将云服务器磁盘(或者说网盘应用)挂载到本地 ，嘿嘿，就我而言很方便我挂载数据到多个服务器上，运行一些不方便拓展的工具，如fsl，FreeSurfer，MATLAB等，不用反复下载删除，这可是极好的。 但就如何开发而言，很遗憾小生了解不多，但找到了别人代码直接用，代码也比较简洁便于学习，在此上 Github 。 这次是真的重点 关于WebDAV这个名词，我百度后给出的答案要么是啥啥啥基于WebDAV的服务广告啊，要么是这个解释 百度百科 WebDAV （Web-based Distributed Authoring

原文地址: http://1.liangtao.sinaapp.com/?p=647 接上一篇文章REST|RESTful初步认识: p=639">http://1.liangtao.sinaapp.com/?p=639 之后,在接下来的了解中也遇到了一些问题,不太懂的Java WebService这一套体系结构,导致对一些技术术语是是而非,对于若干技术，若干规范没有一个总体上的认识。这篇文章即是对Java中RESTful WebService架构相关规范，技术的认识。 Web Service 从表明上来看,Web service就是一个应用程序,它向外界暴露一个可以通过web进行调用的API（无关乎语言、平台）。 从深层次上看,Web service是一种新的web应用程序分支,他们是自包括,自描写叙述,模块化的应用。他遵循一定的技术规范和协议。 因此WebService并非某种详细的技术,他更像是一种标准,实际上webservice就是W3C的标准: Web Services是应用程序组件 Web Services使用开发协议进行通信 Web Services是独立的并可进行自我描写叙述 Web Services可通过使用UDDI来发现 Web services可被其它应用程序使用 对于Web Service先做以上认知就可以。 JWS 指的是与Web

一、简介 1. 什么是REST 　　REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到：“我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。” 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。 　　REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。 特点： REST与技术无关，代表的是一种软件架构风格，REST是Representational State Transfer的简称，中文翻译为“表征状态转移” REST从资源的角度类审视整个网络，它将分布在网络中某个节点的资源通过URL进行标识，客户端应用通过URL来获取资源的表征

01 前言 回归正题，看过很多RESTful相关的文章总结，参齐不齐，结合工作中的使用，非常有必要归纳一下关于RESTful架构方式了，RESTful只是一种架构方式的约束，给出一种约定的标准，完全严格遵守RESTful标准并不是很多，也没有必要。但是在实际运用中，有RESTful标准可以参考，是十分有必要的。 实际上在工作中对api接口规范、命名规则、返回值、授权验证等进行一定的约束，一般的项目api只要易测试、足够安全、风格一致可读性强、没有歧义调用方便我觉得已经足够了，接口是给开发人员看的，也不是给普通用户去调用。 02 RESTful的来源 REST：Representational State Transfer（表象层状态转变），如果没听说过REST，你一定以为是rest这个单词，刚开始我也是这样认为的，后来发现是这三个单词的缩写，即使知道了这三个单词理解起来仍然非常晦涩难懂。如何理解RESTful架构，最好的办法就是深刻理解消化Representational State Transfer这三个单词到底意味着什么。 1.每一个URI代表一种资源； 2.客户端和服务器之间，传递这种资源的某种表现层； 3.客户端通过四个HTTP动词（get、post、put、delete），对服务器端资源进行操作，实现”表现层状态转化”。 是由美国计算机科学家Roy Fielding

RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。 REST（英文：Representational State Transfer，简称REST）描述了一个架构样式的网络系统，比如 web 应用程序。 在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。 原则条件 REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。 在服务器端，应用程序状态和功能可以分为各种资源

该仓库整理了目前比较流行的 RESTful api 设计规范，为了方便讨论规范带来的问题及争议，现把该文档托管于 Github ，欢迎大家补充！！ Table of Contents RESTful API 设计规范 关于「能愿动词」的使用 Protocol API Root URL Versioning 在 URL 中嵌入版本编号 通过媒体类型来指定版本信息 Endpoints HTTP 动词 Filtering Authentication Response 200 ok 201 Created 202 Accepted 204 No Content 3xx 重定向 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 405 Method Not Allowd 406 Not Acceptable 408 Request Timeout 409 Gonfilct 410 Gone 413 Request Entity Too Large 414 Request-URI Too Long 415 Unsupported Media Type 429 Too Many Request 500 Internal Server Error 503 Service Unavailable 版权声明 建议参考

使用步骤： 　　1.在web.xml中配置 <filter> <filter-name>hiddenHttpMethodFilter</filter-name> <filter-class>org.springframework.web.filter.HiddenHttpMethodFilter</filter-class> </filter> <filter-mapping> 　　<filter-name>hiddenHttpMethodFilter</filter-name> 　　<url-pattern>/*</url-pattern> </filter-mapping> 　　@RestController 的使用（@RestController注解相当于@ResponseBody ＋ @Controller合在一起的作用。） 　　　　使用@RestController注解Controller，则Controller中的方法无法返回jsp页面，配置的视图解析器不起作用，返回的内容就是 return 里的内容。 　　　　如果控制器中所有方法都是返回JSON，XML或自定义mediaType内容到页面，则可以在类上加上 @RestController 注解， 　　　　如果需要返回视图，则在类上使用@Controller注解，另外对不返回视图的方法使用@ResponseBody注解

概念: 什么是REST? REST是Representational State Transfer的缩写。翻译为"表现层状态转化",restful是一种接口设计风格,它不是一个协议,通常是基于HTTP协议的; 为什么需要这么一个风格呢? RESTful的重点之一就是统一的接口命名规则; 每个开发者可能会有不同的接口风格,最常见的就类似于于getUserInfo,deleteUserInfo等等.....,但是这个纯粹是跟每个开发者的习惯有关,多人协同开发时就可能会产生问题,特别是前后台分离时,前台人员不得不填写大量各不相同的url来请求数据; RESTful风格: rest将每一个URI都看作是一个资源,这是一个概念,实际可以是一个图片,一条记录,一组记录都可以; 每一种请求方法都对应着对某个资源的操作,通常包含以下四种: GET 获取资源 PUT 更新资源 POST 提交资源 DELETE 删除资源 假设我们将id为1的用户数据看做是一个资源,那么我们要在前台操作这个资源时就要向服务器发送能够定位这个资源的请求地址,如:http://localhost:8080/SSMDemo/user/1 ,通过URI找到资源后,我们还要告诉服务器我们要对这个资源进行什么样的操作,就通过HTTP的请求方法;如GET 简单的说: RESTful就是用URI来定位资源