rest api,（二）Django REST实践：最简单的REST API实现
rest api,（二）Django REST实践：最简单的REST API实现详细介绍
本文目录一览： 什么是REST API？请解释的通俗一点,它和一般的API有什么区别
就是传统的 {增, 删, 改, 查} 数据库的条件写在了{ POST, DELETE, PUT, GET }里。
URL不用设计，可以直接生成。
知道标准的前端工程师可以访问整个数据库，再也不用问后端同事要接口了！
REST API是一组关于如何构建Web应用程序API的架构规则、标准或指导，REST API遵循API原则的架构风格。REST是专门针对Web应用程序而设计的，其目的在于降低开发的复杂度，提高系统的可伸缩性。
REST API和一般的API区别为：包含不同、资源不同、状态不同。
一、包含不同
1、REST API：REST API 是API的子集；所有的REST API都是API。
2、一般的API：一般的API的为。API是REST API的超集，不是所有的API都是REST API。
二、资源不同
1、REST API：在REST API架构中，每一个资源都有与之对应的唯一资源标识符（resource identifier），当资源的状态发生改变时，资源标识符不会发生改变。
2、一般的API：一般的API架构中，Web中所有的事物（文本、音频、视频、图片、链接）被统一的抽象为资源（resource）。当资源的状态发生改变时，资源标识符会发生改变。
三、状态不同
1、REST API：在REST架构中，所有的操作都是无状态的。REST架构不遵循CRUD原则。
2、一般的API：一般的API架构中，所有的操作都是有状态的。遵循CRUD原则，所有的资源都可以通过GET、POST、PUT和DELETE这四种行为完成对应的操作。
什么是REST API
REST APL指一组架构约束条件和原则，满足约束条件和原则的应用程序设计。架构，软件体系结构分为三部分：构建，用于描述计算机；连接器，用于描述构建的链接部分；配置将构建和连接器组成有机整体。
拓展资料：rest，即REST（RepresentationalStateTransfer表述性状态转移）是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。现如今在三种主流的Web服务实现方案中，因为REST模式的Web服务与复杂的SOAP和XML-RPC开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。
一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
拓展内容：
原则条件：
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
定义规则：
REST中的资源所指的不是数据，而是数据和表现形式的组合，比如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。
资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是XML（标准通用标记语言下的一个子集）格式、txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。
一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
拓展内容：
原则条件：
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
定义规则：
REST中的资源所指的不是数据，而是数据和表现形式的组合，比如“最新访问的10位会员”和“最活跃的10位会员”在数据上可能有重叠或者完全相同，而由于他们的表现形式不同，所以被归为不同的资源，这也就是为什么REST的全名是Representational State Transfer的原因。
资源标识符就是URI(Uniform Resource Identifier)，不管是图片，Word还是视频文件，甚至只是一种虚拟的服务，也不管你是XML（标准通用标记语言下的一个子集）格式、txt文件格式还是其它文件格式，全部通过 URI对资源进行唯一的标识。
REST的全拼是（REpresentational State Transfer，表述性状态转移）。REST指的是一组架构约束条件和原则，满足这些约束条件和原则的应用程序设计就是RESTful。
REST指一组架构约束条件和原则，满足约束条件和原则的应用程序设计。架构，软件体系结构分为三部分：构建，用于描述计算机；连接器，用于描述构建的链接部分；配置将构建和连接器组成有机整体。
Rest API，无论它的名字多么高大上，它本质还是一个HTTP请求，POST也好，GET也罢，都是不同的数据提交方式。所以，能够决定一个Rest API的也就：URI、参数、请求方式、请求头等。API平台的架构，其实和底层公司的业务系统架构有着密切的关系，基于一个好的系统架构写一个Rest API平台基本是水到渠成的。
Rest API 开发 学习笔记 概述
REST 从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表示方式。获得这些表徵致使这些应用程序转变了其状态。随着不断获取资源的表示方式，客户端应用不断地在转变着其状态，所谓表述性状态转移（Representational State Transfer）。
这一观点不是凭空臆造的，而是通过观察当前Web互联网的运作方式而抽象出来的。Roy Fielding 认为，
“设计良好的网络应用表现为一系列的网页，这些网页可以看作的虚拟的状态机，用户选择这些链接导致下一网页传输到用户端展现给使用的人，而这正代表了状态的转变。”
REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。
资源是由URI来指定。
对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
通过操作资源的表现形式来操作资源。
资源的表现形式则是XML或者HTML，取决于读者是机器还是人，是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式。
REST的要求
客户端和服务器结构
连接协议具有无状态性
能够利用Cache机制增进性能
层次化的系统
随需代码 - Javascript （可选）
RESTful Web 服务
RESTful Web 服务（也称为 RESTful Web API）是一个使用HTTP并遵循REST原则的Web服务。它从以下三个方面资源进行定义：URI，比如：http://example.com/resources/。
§ Web服务接受与返回的互联网媒体类型，比如：JSON，XML ，YAML 等。
§ Web服务在该资源上所支持的一系列请求方法（比如：POST，GET，PUT或DELETE）。
该表列出了在实现RESTful Web 服务时HTTP请求方法的典型用途。
HTTP 请求方法在RESTful Web 服务中的典型应用
资源
GET
PUT
POST
DELETE
一组资源的URI，比如http://example.com/resources/
列出 URI，以及该资源组中每个资源的详细信息（后者可选）。
使用给定的一组资源替换当前整组资源。
在本组资源中创建/追加一个新的资源。 该操作往往返回新资源的URL。
删除 整组资源。
单个资源的URI，比如http://example.com/resources/142
获取 指定的资源的详细信息，格式可以自选一个合适的网络媒体类型（比如：XML、JSON等）
替换/创建 指定的资源。并将其追加到相应的资源组中。
把指定的资源当做一个资源组，并在其下创建/追加一个新的元素，使其隶属于当前资源。
删除 指定的元素。
PUT 和 DELETE 方法是幂等方法。GET方法是安全方法 （不会对服务器端有修改，因此也是幂等的）。
不像基于SOAP的Web服务，RESTful Web服务并没有的“正式”标准。 这是因为REST是一种架构，而SOAP只是一个协议。虽然REST不是一个标准，但在实现RESTful Web服务时可以使用其他各种标准（比如HTTP，URL，XML，PNG等）。
REST的优点
可以利用缓存Cache来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
浏览器即可作为客户端，简化软件需求
相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好
http://wenku.baidu.com/view/74f6e4bec77da26925c5b036.html.(可以看一下）
REST 是REpresentational State Transfer的缩写，字面的翻译是表现层状态转移。
RESTful API就是REST风格的网络接口，REST描述的是在网络中client和server的一种交互形式；REST本身不实用，实用的是如何设计。
Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。“资源”是REST架构或者说整个网络处理的核心。
拓展资料:
REST指一组架构约束条件和原则，满足约束条件和原则的应用程序设计。架构，软件体系结构分为三部分：构建，用于描述计算机；连接器，用于描述构建的链接部分；配置将构建和连接器组成有机整体。
web基本技术：URI（统一资源标示符）HTTP（超文本传输协议）（post、get、put、delete） Hypertext。
1、每个资源都应该有唯一的一个标识
2、使用标准的方法更改资源的状态
3、request和response的自描述
4、资源多重表述
5、无状态服务
用HTTP协议里的动词来实现资源的添加，修改，删除等操作。即通过HTTP动词来实现资源的状态扭转：
GET 用来获取资源
POST 用来新建资源（也可以用于更新资源）
PUT 用来更新资源，
DELETE 用来删除资源。
Kubernetes 的REST API指的是什么？
rest assured 是一个固定搭配用法，表示“放心;确信无疑”。所以you can rest assured就是“你大可放心”的意思。
例句：
You can rest assured, sir, that not oneof them said anything like that.
你可以放心,他们不会说什么的。
You can rest assured that we will do our best.
你放心吧,我们会尽力而为的.
I will not attack until we are ready, and you can rest assured on that point.
在咱们准备好之前,我决不进攻;这一点, 大家可以放心。
REST API是Kubernetes系统的重要部分，组件之间的所有操作和通信均由API Server处理的REST API调用，大多数情况下，API定义和实现都符合标准的HTTP REST格式，可以通过 kubectl命令管理工具或其他命令行工具来执行。
API 版本
为了在兼容旧版本的同时不断升级新的API，Kubernetes支持多种API版本，每种API版本都有不同的API路径，例如/api/v1或 /apis/extensions/v1beta1。
API版本规则是通过基于API level选择版本，而不是基于资源和域级别选择，是为了确保API能够描述一个清晰的连续的系统资源和行为的视图，能够控制访问的整个过程和控制实验性API的访问。
JSON和Protobuf序列化模式遵循相同的模式变化原则，以下所有描述都涵盖了这两种模式。
需要注意，API版本和软件的版本没有直接关系，不同API版本有不同程度稳定性，API文档中详细描述了每个级别的标准。
Alpha级别：包含alpha名称的版本（例如v1alpha1）。该软件可能包含错误。启用一个功能可能会导致bug。默认情况下，功能可能会被禁用。随时可能会丢弃对该功能的支持，恕不另行通知。API可能在以后的软件版本中以不兼容的方式更改，恕不另行通知。该软件建议仅在短期测试集群中使用，因为错误的风险增加和缺乏长期支持。
Beta级别：包含beta名称的版本（例如v2beta3）。该软件经过很好的测试。启用功能被认为是安全的。默认情况下功能是开启的。细节可能会改变，但功能在后续版本不会被删除对象的模式或语义在随后的beta版本或Stable版本中可能以不兼容的方式发生变化。如果这种情况发生时，官方会提供迁移操作指南。这可能需要删除、编辑和重新创建API对象。该版本在后续可能会更改一些不兼容地方，所以建议用于非关键业务，如果你有多个可以独立升级的集群，你也可以放宽此限制。大家使用过的Beta版本后，可以多给社区反馈，如果此版本在后续更新后将不会有太大变化。
Stable级别：该版本名称命名方式：vX这里X是一个整数。Stable版本的功能特性，将出现在后续发布的软件版本中。
Kubernetes API 概述
讨RESTAPI设计方面的最佳实践
由于REST可以降低开发的复杂度，提高系统的可伸缩性，增强系统的可扩展性，简化应用系统之间的集成，因而得到了广大开发人员的喜爱，同时得到了业界广泛的支持。比如IBM，Google等公司的很多产品都提供了REST API给开发人员；与此同时，大量的开源项目和云计算服务都提供了REST API接口。
而在最近，一些新产品的开发甚至已经几乎完全抛弃了传统的类似JSP的技术， 转而大量使用REST风格的构架设计， 即在服务器端所有商业逻辑都以REST API的方式暴露给客户端， 所有浏览器用户界面使用widget、Ajax、HTML5 等技术，用HTTP的方式与后台直接交互。
那么， 在REST API爆炸式增长的今天， 我们应该如何更好的设计我们的接口， 来提高我们的API的可用性，易用性，可维护性与可扩展性呢？本文将从以下方面与您探讨REST API设计方面的最佳实践：
如何规划资源标识结构与URI模式
如何根据应用场景提供内容协商
如何正确的使用HTTP响应代码
如何处理缓存和并发请求
如何利用数据冗余和链接元素
先决条件
如果您具有如下知识与经验，将有助于您阅读和理解本文章的内容 。
REST相关的基本知识；
HTTP协议的基本知识；
一定的Web开发经验。
REST简介
REST是英文 State Transfer的缩写，是近年来迅速兴起的，一种基于HTTP、URI以及XML这些现有协议与标准的，针对网络应用的设计和开发方式。它可以降低开发的复杂度，提高系统的可伸缩性。
REST的核心是可编辑的资源及其集合，用符合Atom文档标准的Feed和Entry表示。每个资源或者集合有一个惟一的URI。系统以资源为中心，构建并提供一系列的Web服务。REST的基本概念和原则包括：系统上的所有事物都被抽象为资源；每个资源对应唯一的资源标识；对资源的操作不会改变资源标识本身；所有的操作都是无状态的；等等。
在REST中，开发人员显式地使用HTTP方法，对系统资源进行创建、读取、更新和删除的操作：
使用POST方法在服务器上创建资源
使用GET方法从服务器检索某个资源或者资源集合
使用PUT方法对服务器的现有资源进行更新
使用DELETE方法删除服务器的某个资源
图 1. 用 HTTP 方法操作相册系统资源的简单范例
更好的规划你的资源标识结构与URI模式
REST 中，最基本的莫过于资源标识结构和URI模式了。更好的规划他们，是我们的API设计取得成功的最关键的一步。
首先，我们来看看基本资源类型
上文中提到，在REST构架的设计中，系统中的所有事物都被抽象为资源。
在一个文档系统中，文档、目录、注释、草稿等等，是组成系统的资源。
在一个银行系统中，客户信息、理财产品、利率信息、网点信息等等，是组成系统的资源。
在一个航空客票系统中，旅客信息、机票订单、航班信息、机场信息等等，是组成系统的资源。
这些资源，通常在系统中以“Entry”的形式出现。下面的代码样例向您展示了一个常见的“Entry”资源。
清单 1. 一个简单的Entry资源样例
以下是引用片段：
REST API 请求：
GET example/航班信息/CA827/entry
CA827
CA827
2010-08-24T02:35:40.937Z
2010-08-24T02:35:40.937Z
Beijing
Changsha
09:30:00
AB330
我们会注意到，这些资源，在描述了某种事物的同时，还有可能存在一定的层次结构关系。比如，文档从属于某个目录，注释从属于文档；旅客信息可以从属于机票订单，也可以从属于某个航班。
当我们的资源有这种层次关系的时候，我们不妨在URI模式的设计中，用复合的URI来帮助开发者更好的理解和设计资源。
比如， 针对一个文档的评论， 他的URI模式可以设计成如下：/文件夹/[文件夹名]/文件/[文件名]/评论/[ 评论唯一标示 ]。 这样，在构造和解析URI的过程中， 可以帮助开发者更好的理解系统，设计程序。
其次，我们来看看集合资源类型
资源，除了作为独立个体可以被访问，还可以由多个个体组合成一个集合，在系统中，通常以“feed”的形式存在。资源的集合， 可以是处于相同层次上，有相同从属关系的一组资源，比如一个文件夹下的所有文件； 也可以是根据某种条件查询出来的查询结果的资源集合，比如所有30岁以上40岁以下，拥有100万资产以上客户的名单。
下面，我们来讨论一下设计集合类型资源的REST API时需要考虑的问题。
使用过滤条件来帮助用户更准确地获取数据
我们要返回的资源集合，无论是否有相同从属关系，大部分时候都需要进行必要的过滤，提供足够的过滤参数，查询参数， 能够帮助开发者高效的，准确地获取所需要的数据。 在服务器端过滤数据通常比客户端高效，并且减少了不必要的数据传输，可以大大减少网络开销，提高执行效率。
最常见的过滤条件，是通过URL参数实现，比如/环境工程系/学生?籍贯=北京&性别=女。
很多时候，我们需要制定更加复杂的过滤条件，那么我们可以有两种选择：
首先，我们可以使用正则表达式或者服务器可以理解的语法，比如/环境工程系/学生?filter=age between (15, 18)
其次，我们还可以使用POST方法，携带一个文件来描述复杂的查询条件，文件的格式与语法通常需要在服务器端有相应的设计与定义。不过通常POST方法没有缓存机制，因此不是查询数据的首选。
使用排序来帮助客户端更好的展现数据
虽然进行客户端排序对于开发者来说是件轻而易举的事情，但是直接得到已经排序的返回结果，仍然是大部分开发者所期望的。尤其是很多时候，我们在浏览器，使用 Widget 展示结果，不适宜在客户端存储大量数据进行内存排序。
排序， 通常有2个参数，一个是用来排序的字段，一个是排序的升序降续方式。比如我们可以用支持这样的参数组合的手段，提供基本的排序能力：?sortOrder=asc&sortField=age
使用分页来帮助客户端处理大量数据
由于返回的结果可能有几百几千条记录，将这些记录一次性的返回给客户端是不现实的，巨大的网络流量开销和客户端数据区的内存开销，都是我们在应用开发的时候不希望看到的，因此，如果你的集合资源有可能有大量的数据返回，请务必提供分页的功能支持。
我们通常用一个以上参数来制定一个返回结果的区域，比较常见的有下面两种：
一种常见于用固定行数的表格来展示数据，用当前处于第几页和每页返回多少行数据来确定需要的数据， 比如/所有学生?page=5&pagesize=50
另外一种常见于用更加灵活的界面展示数据，用从第几行开始，一共返回多少行数据来确定需要的数据， 比如/所有学生?startIndex=27&count=22
下面是一个来自IBM 的API样例，尝试请求该API，你可以看到该集合很好的支持了结果的分页与排序。同时我们从返回的信息中可以看到，每个文档Entry的URI都按照/社区库/[社区库ID]/文档/[文档ID]的复合URI的模式设计的。
清单 2. IBM 的某个社区文件库的集合资源的API
以下是引用片段：
REST API 请求：
GETIBM 的文件服务标签云的API
以下是引用片段：
REST API请求，要求返回XML格式数据：
GETibm//
/files/form/anonymous/api/tags/feed?format=json
&scope=document&pageSize=30&sK=cloud&sO=dsc
使用Aept头进行内容协商
使用URL参数，简单灵活，但是也由此带来了设计上的随意和不标准。并且，过多的参数会导致URL的可读性变差，更有甚者，可能会导致URL过长，超出规范，API请求无法执行。
更为标准的内容协商方式是使用HTTP头。我们通常使用Aept来设置我们接受的返回结果的内容格式，用Aept-Charset来设置字符集，用Aept-Encoding来设置数据传输格式，用Aept-Language来设置语言。
使用URI模式进行内容协商
还有一种模式，就是将协商设置直接作为URI的一部分，将不同的返回视为不同的资源，比如/航班号/json来返回JSON格式的结果，用/航班号/atom来返回ATOM格式的结果。
正确的使用HTTP响应代码
作为API的设计者，正确的将API执行结果和失败原因用清晰简洁的方式传达给客户程序是十分关键的一步。 我们确实可以在HTTP的相应内容中描述是否成功，如果出错是因为什么， 然而， 这就意味着用户需要进行内容解析，才知道执行结果和错误原因。因此，HTTP响应代码可以保证客户端在第一时间用最高效的方式获知API运行结果，并采取相应动作。
转载，仅供参考，祝你愉快，满意请采纳。
（二）Django REST实践：最简单的REST API实现
本小节大概要花费10分钟。
在前面，我们已经学会了Django如何获得HTTP请求中的内容，以及如何获取HTTP请求的body。接下来我们就来写一个最简单的API。这个API要求在请求的HTTP body中放入JSON格式的文本，并在解析文本后进行处理，返回JSON格式的数据。
我们定义 API的URL为/api/sum/，功能是为两个数求和，并返回。
request中body的格式为：
response的格式为：
response中，我们的数据结构稍微有点复杂。
之后我们所有的REST API都会以这种统一的格式返回数据，两个不同REST API所返回内容的主要区别在data域上。
在（一）中，我们建立了一个叫做task_platform的Django项目。目录结构如下：
进入Django项目目录，并编辑task_platform中的views.py文件。
其中：
编辑task_platform/urls.py，将我们刚刚实现的API处理函数加入到路由表中。
运行Django server：
用Postman模拟请求，可以看到：
经过练习，我们已经了解如何实现一个简单的REST API了！我们之后的API都是建立在这个通讯模型之上的（当然还有一些使用GET方法的API）。在后面，我们将看看，如何通过这种模式，实现一个用户认证系统的REST API。
REST API 和WebService有哪些不同
rest api属于webService的其中一种请求样式：你应该想问的是REST 样式和 SOAP 样式 的区别吧？
从基本原理层次上说，REST 样式和 SOAP 样式 Web Service的区别取决于应用程序是面向资源的还是面向活动的。例如，在传统的WebService中，一个获得天气预报的webservice会暴露一个WebMethod：string GetCityWether（string city）。而RESTful WebService暴露的不是方法，而是对象（资源），通过Http GET, PUT, POST 或者 DELETE来对请求的资源进行操作。在 REST 的定义中，一个 Web Service总是使用固定的 URI 向外部世界呈现（或者说暴露）一个资源。可以说这是一种全新的思维模式：使用唯一资源定位地址 URI，加上 HTTP 请求方法从而达到对一个发布于互联网资源的唯一描述和操作。
最后，如果你已经有相关接口，若需要测试，推荐eolinker，可视化界面 ，支持自动生成文档，支持Mock数据，自动化测试，生成SDK，团队协作等等。eolinker也是目前国内最大的在线接口管理平台~
ArcGIS Server REST 服务各类API的主要功能
这个问得比较大，REST是一个Web应用程序框架。ArcGIS REST API提供了简单、开放的接口来访问和使用ArcGIS Server发布的服务。使用ArcGIS REST API通过URL，可以获取和操作每一个服务中的所有资源和操作。使用REST API就是通过URL来向GIS服务器获取资源的操作。
一般客户端从服务器端总是能得到一个资源的表现，在此一般分为两种类型的资源：
Resources（资源，直接反应了服务本身的信息）
Operations（操作，根据服务本身的资源进行某些处理后得到的结果）
Catalog是整个REST APIURL分层等级的根。根下面是这个Server所发布的服务，一共有8种类型的服务：Map Service、Geocode Service、GP Service、Geometry Service、Image Service、Network Service、GeoData Service和Globe Service。每一种Service下面都有不同的操作和资源，而执行这些操作和获取这些资源都是通过URL。
再具体的建议参考《ArcGIS Server REST API Help》。
confluence开放RestAPI的灵活使用和集成
confluence提供了开放的REST API，可以使用REST API与Confluence实体（例如页面和博客文章，空间，用户，组等）进行交互。传送门 Confluence Cloud REST API
本文主要会针对Confluence Cloud REST API中的开放接口进行简要的介绍，并以创建confluence页面为例子描述如何使用其开放的RestAPI
扫了一眼接口文档，开放的接口实在太多了，就随便挑几个列出来，其他的去官方文档自取吧。。
GET / wiki / rest / api / space header ：Accept: application/json
POST /wiki/rest/api/space
BODY PARAMETERS key REQUIRED string name REQUIRED string description permissions
GET /wiki/rest/api/content header ：Accept: application/json
GET /wiki/rest/api/content/{id} header ：Accept: application/json
POST /wiki/rest/api/content
BODY PARAMETERS 略，自己看
【不想写了，晚点补充】
以创建一个confluence为例来介绍如何使用该API，此次示例基于jmeter（postman也可以，用法同理）
直接使用RESTAPI的时候需要进行身份认证，方法和JIRA一样，说明书在此 身份验证方法 步骤如下：
API中创建内容的URL为 https://your-domain.atlassian.net/wiki/rest/api/content 在这里经过调试发现了一个坑，填URI的时候路径带了/wiki，怎么都跑不通，后来看了别人的教程，别人的教程里面URI里不带/wiki，于是我也去掉后再次调试，就能调通了。 因此请求体用下图一次性说明，post body具体怎么填详见API，有需求来看我文章的人肯定能看懂API了
对几个字段进行说明： 1、host：填你目前使用的confluence的域名 2、内容编码：title如果是有中文，一定要填入utf-8。填在头里也可以 3、id：id为自己定义的一串数字，长度为8，经过测试发现，并没有什么卵用，confluence会自己生成id 4、ancestors内的id：重要，是你创建的页面的父页面的id 5、value：填的是你要创建的页面的html编码标签，如果要创建一个带表格的页面，就要写成图里这样 6、key空间的key，可以从空间管理中找到，空间管理中的“标识”字段
按照以上方法，请求接口就可以在confluence上看到创建的页面了 出来的页面：
rest api为什么使用http状态码
所有浏览器用户界面使用 widget，Ajax，HTML5 等技术，用 HTTP 的方式与后台直接交互。
那么， 在 REST API 爆炸式增长的今天， 我们应该如何更好的设计我们的接口，
来提高我们的 API 的可用性，易用性，可维护性与可扩展性呢？
本文将从以下方面与您探讨 REST API 设计方面的最佳实践：
1). 如何规划资源标识结构与 URI 模式
2). 如何根据应用场景提供内容协商
3). 如何正确的使用 HTTP 响应代码
4). 如何处理缓存和并发请求
5). 如何利用数据冗余和链接元素
二、先决条件
如果您具有如下知识与经验，将有助于您阅读和理解本文章的内容 。
. REST 相关的基本知识；
. HTTP 协议的基本知识；
. 一定的 Web 开发经验。
restapi怎么实现文件上传
第二部：创建工具类
public class WinkUtils {
public static ClientConfig getClientConfig(){
ClientConfig config=new ClientConfig();
SSLContext sc;
try {
sc=SSLContext.getInstance("SSL");
sc.init(null, getTrustManager(), new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
config.setBypassHostnameVerification(true);
config.connectTimeout(100000);
config.readTimeout(100000);
config.followRedirects(false);
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
} catch (KeyManagementException e) {
e.printStackTrace();
}
return config;
}
public static TrustManager[] getTrustManager(){
TrustManager[] trustAllCerts=new TrustManager[]{ new X509TrustManager(){
public void checkClientTrusted(X509Certificate[] arg0,String arg1) throws CertificateException {}
public void checkServerTrusted(X509Certificate[] arg0,String arg1) throws CertificateException {}
public X509Certificate[] getAcceptedIssuers() {
return null;
}
}
};
return trustAllCerts;
}
}
第三步：写入图片数据到Bmob上
/**
* 功能：根据传入的url路径插入图片数据
* @param url 上传图片的url路径
* @param data 传入到Bmob中的图片二进制数据
* @return 插入成功返回的json格式字符串
*/
public static String setInsertGoodsData(String url,byte[] data){
String result=null;
RestClient restClient=new RestClient(WinkUtils.getClientConfig());
Resource resource=restClient.resource(url);
resource.header("X-Bmob-Application-Id", "你自己的APPID");
resource.header("X-Bmob-REST-API-Key",“你自己的APPKEY”);
resource.header("Content-Type", "image/jpeg");
ClientResponse response=resource.post(data);
int code=response.getStatusCode();
System.out.println("结果码:"+code);
if(code==201){
result=response.getEntity(String.class);
}
return result;
}
根据返回的result当中就包含图片上传之后在Bmob上的路径。操作完毕。