rest 接口开发（rest api接口开发）

本篇文章给大家谈谈rest 接口开发，以及rest api接口开发对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享rest 接口开发的知识，其中也会对rest api接口开发进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、REST接口是什么？（译文）
• 2、java开发 Rest 接口怎样设计api_key 也就是我的api怎样才能不被自由访问，需要在header加入验证
• 3、使用C#快速搭建Rest服务
• 4、REST接口规范
• 5、如何理解rest和restful，什么是restfulAPI?
• 6、RESTful接口详解

REST接口是什么？（译文）

—— evilrescuer 翻译自 Ruben Verborgh 写的 《What is a REST API?》

REST是不同于其他系统的一种描述网页如何架构的方法。

Web是一种可以轻易地通过你的浏览器访问的，位于因特网最上层的信息网络。在许多方面，它有着和其他计算机系统不同的架构。

REST是一种用来设计系统（如Web）的架构风格。REST最典型的特征就是 统一接口的四个约束。 REST接口遵循这四个规范。

约束1：提供通过资源的访问

在典型的计算机系统中，客户端和服务器交换命令：做这个，做那个。假设我们想用非REST的方式模拟一个to-do列表，用技术语言，这可能长这样：

非REST

注意，它的的确确是一条指令：改变某个东西。
但“changeTodoList”不是一个东西，不是一个资源。

在REST架构风格里，服务器仅仅提供资源。资源是概念上客户端和服务器通讯的东西。

REST

上面这串东西不是一个命令，而是一个资源、一个东西的地址。你可以使用这个地址，用标准的方法去操纵to-do列表，而不是用特定接口的命令。

约束2：通过陈述表现资源

一个资源是我们能用不同的格式描述的东西。例如，人们可能想理解由浏览器转换成的可读布局的HTML版本。但有时Web上的接口是提供给机器使用的，它们需要一个不同的格式，如JSON。

通过非REST的方式，不同的格式具有不同的地址：

非REST

那么问题来了。这两个使用不同格式的系统彼此间无法通讯，因为它们在同一个东西上用不同的地址。

在REST系统中，地址与东西一致，而非格式，所以所有的系统在同一个东西上用同一个地址。那它们怎么获取不同格式的这个东西呢？它们明确地提出请求！

REST

使上面的方案可行的技术被称为 内容协商 。

约束3：交换自描述信息

在REST系统中，我们可以在不知道之前的信息时，单独解释任何一条信息。

想象一下下面的会话：

非REST

第一个请求获取“todo”的查询结果；第二个请求获取第二页的查询结果；现在想象一下，你只看到了第二条请求，你怎么知道服务器接下来要做什么呢？

在REST中，每条信息都自力更生：

REST

注意每条请求是如何通过自身来解读的。
另一方面，REST客户端和服务器只采用描述里定义的标准操作。对Web来说，这个描述就是 HTTP 。

约束4：通过链接连接资源

你怎么导航到一个你从没有见过的网页？你使用链接！
当你访问一个新页面时，你不需要每次手动地编辑浏览器的地址栏。

在机器接口中，却并不尽然。假设一个应用请求to-do列表。它可能接收如下的描述：

非REST

现在你要如何获取这个列表中的各个项呢？
问得好！我们需要读一下相关的文件。

在REST中，资源彼此间通过超级链接连接在一起：

REST

{
    "name":"My to-dos",
    "items":["/todolists/7/items/35/","/todolists/7/items/36/"]
}

注意你是如何不通过手动的方式知道如何取得列表中的各个项的。其实，你只需要跟随着链接就好了。

遵循这些约束的接口就是REST接口

在你的接口里，遵循这四条约束，你就拥有了一个REST接口

不幸的是，许多自称是“REST”的接口，实际上只是其他的东西（“HTTP接口”），因为它们并不完全遵循所有这些约束。约束2和约束4常常被违反，但也很少见到违反约束1的。对这些开发者来说，“REST”简单地意味着“我们没有XML信息”。

这也是为什么遵循所有这四个约束的REST接口，如今常常被称为“超媒体接口”，这点与第四个约束有关。

java开发 Rest 接口怎样设计api_key 也就是我的api怎样才能不被自由访问，需要在header加入验证

以下仅供参考:
如果rest端要自己维护api_key,类似存储在数据库里,就分发(授权)给客户端某个api_key,然后客户端用api_key和一些其他条件如时间戳+签名去rest端换取一个token,最后客户端用这个token和rest端进行交互,可以参考下微信的oauth鉴权.
如果rest端不维护api_key,也就省去分发(授权)客户端api_key的工作,此时客户端用传递的参数和其他条件如时间戳+签名去rest端换取一个token..同上
上述所说的token都是唯一的,对于同一个客户端的请求而言,下次刷取token的时候,之前产生的token作废;
token本身应该要维持在rest端,也应该有一个过期的限制;
(参数)+(api_key)+时间戳 通过加密算法(如sha2)生成签名,rest端同逻辑校验签名是否合法一般就能卡掉一大部分的访问,
至于api_key或者token放在哪里,一般无状态访问比较常见是在head里(常见如angularjs项目),这里我觉得随意,因为只要被拦截都可见,只是head可以放比较多的东西用来障目就是了.
当然,如果正在用的token被拦截,同样也是可以随意访问的,因此可能要求https协议加证书应该会更牢固点(没试过);
一般就这样,再高的我也不懂了,如果陈述有什么问题,者有什么看法,也还请不吝赐教~

使用C#快速搭建Rest服务

为了能够在桌面端软件中简单方便rest 接口开发的对外提供RestApi接口rest 接口开发，参考Java SpringMVC框架使用C#语言编写了一个简易RestApi服务器框架，目前支持rest 接口开发：

- 静态页面处理

- GET/POST/PUT/DELETE请求

- 支持返回JSON

- 支持路由方法

- 支持自定义过滤器

- 服务器返回数据支持gzip压缩

- 支持Component变量自动注入

- 支持Component自动扫描

- GET/POST支持查询参数，POST支持body数据

- 注解支持

  - Component

  - WebFilter

  - RequestMapping

  - Autowired

  - RequestBody

  - RequestParam

new RestApplicationServer().run(new RestConfiguration {

    StaticFileConfigurations = new List<StaticFileConfiguration() {

        new StaticFileConfiguration("/e", "E:\\"),

        new StaticFileConfiguration("/f", "F:\\")

    }

});

// 将 http://xxxxx.com/e/xxxxx 映射到本地磁盘文件 E：\\xxxxx

// 将 http://xxxxx.com/f/xxxxx 映射到本地磁盘文件 F：\\xxxxx

1.添加Controller

        [Component("PersonController")]

    public class PersonController

    {

        [Autowired]

        public PersonService personService;

        private ILogger logger = LoggerFactory.GetLogger();

        [RequestMapping("GET","/api/person/list")]

        public List<Person GetPersonList()

        {

            return personService.GetPersonList();

        }

        [RequestMapping("GET", "/api/person")]

        public Person GetPerson([RequestParam("id")]int id)

        {

            logger.Debug("id:"+id);

            return personService.GetPerson((int)id);

        }

        [RequestMapping("POST", "/api/person")]

        public string Create([RequestBody] Person person)

        {

            logger.Info("person:" + person.ToString());

            return "ok";

        }

    }

2.添加Service

    [Component("PersonService")]

    public class PersonService

    {

        private ILogger logger = new ConsoleLogger();

        public List<Person GetPersonList() {

            return TestData.PersonList;

        }

        public Person GetPerson(int id)

        {

            return TestData.PersonList.Find(x = x.id == id);

        }

        public void Create(Person person)

        {

            logger.Debug(person.ToString());

        }

    }

3.启动服务

controller和service上增加Component注解后，服务启动时会进行自动扫描

class Program

{

    static void Main(string[] args)

    {

        new RestApplicationServer().run();

    }

}

1. 添加一个计算接口处理耗时的filter

[WebFilter(1, "/")]

    public class StopWacthFilter : IFilter

    {

        public void Filter(HttpRequest request,ref HttpResponse response, ProcessChain chain, int nextIndex)

        {

            Stopwatch stopwatch = new Stopwatch();

            stopwatch.Start();

            chain.doFilter(request,ref response, nextIndex);

            stopwatch.Stop();

            Console.WriteLine(request.Method + " "+request.Path+ ", 耗时："+(stopwatch.ElapsedMilliseconds).ToString()+"ms");

        }

    }

自定义filter上增加WebFilter注解后，服务启动时会进行自动扫描
项目地址： https://github.com/13401095975/RestServer

REST接口规范

资源URL设计原则

REST风格规定所有资源通过统一资源定位符（URL）定位，资源的RESTful URL采用以下模板：
http(s)://ip:port/(rest)/{service-name}/{version}/{rest-convention}
一个完整URL由服务接口入口、服务接口标识（rest）、服务名称{service-name}、版本号{version}、服务内资源路径{rest-convention}组成，其中服务接口标识"/rest"非规范强制要求

如：获取所有角色基本信息 http://localhost:8086/rest/uam/v1/roles
【规则】若服务接口归属于固定域名，ip:port应该由域名替代。
【规则】URL中字段命名采用英文半角小写字母、数字、中划线或下划线组合，如"search-by-group"，不建议采用驼峰式命名。
【规则】URL长度应小于2083字符，否则服务端返回414状态码
【规则】URL中不能包含URL特殊字符（RFC1738标准），特殊字符需使用特殊字符时需要做URL encode。
【规则】URL中不得包含公司安全红线涉及的敏感信息。
【建议】website暴露给WebUI的RESTful采用模板：
http(s)://ip:port/(rest)/{website-name}/ui/{version}/{rest-convention}
说明：为保持系统对外接口风格一致，在{website-name}和{version}之间添加"ui"标识当前接口为website对外提供的接口。

如何理解rest和restful，什么是restfulAPI?

简单理解一
就是用URL定位资源，用HTTP描述操作。
简单理解二
URL定位资源，用HTTP动词(GET,POST,DELETE,DETC)描述操作。
官方定义
一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
以web开发举例
在设计web接口的时候，REST主要是用于定义接口名，接口名一般是用名次写，不用动词，那怎么表达“获取”或者“删除”或者“更新”这样的操作呢——用请求类型来区分。
比如，我们有一个students接口，对于“学生”我们有增删改查四种操作，怎么定义REST接口？
增加一个学生，uri: http://testcode.com/school/students 接口类型：POST
删除一个朋友，uri: http://testcode.com/school/students 接口类型：DELETE
修改一个朋友，uri: http://testcode.com/school/students 接口类型：PUT
查找朋友，uri: http://testcode.com/school/students 接口类型：GET
上面我们定义的四个接口就是符合REST协议的，请注意，这几个接口都没有动词，只有名词students，都是通过Http请求的接口类型来判断是什么业务操作。
举个反例
uri: http://testcode.com/school/addStudents 该接口用来表示增加学生，这就是不符合REST协议的接口。
建议
用HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误，403表示Bad Request等。(反例：传统web开发返回的状态码一律都是200，其实不可取。)
REST风格接口意义
前后端分离。前端拿到数据只负责展示和渲染，不对数据做任何处理。后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，在web，ios，android三端都可以用相同的接口，节约开发成本以及便于同一调试。

RESTful接口详解

REST是英文representational state transfer(表象性状态转变)或者表述性状态转移;Rest是web服务的一种架构风格;使用HTTP,URI,XML,JSON,HTML等广泛流行的标准和协议;轻量级,跨平台,跨语言的架构设计;它是一种设计风格,不是一种标准,是一种思想

Rest架构的主要原则：

符合REST原则的架构方式即可称为RESTful

什么是Restful:
对应的中文是rest式的;Restful web service是一种常见的rest的应用,是遵守了rest风格的web服务;rest式的web服务是一种ROA(The Resource-Oriented Architecture)(面向资源的架构).

为什么会出现Restful

在Restful之前的操作：
user/query/1 GET 根据用户id查询用户数据
user/save POST 新增用户
user/update POST 修改用户信息
user/delete/1 GET/POST 删除用户信息

RESTful用法：
user/1 GET 根据用户id查询用户数据
user POST 新增用户
user PUT 修改用户信息
user DELETE 删除用户信息

之前的操作是没有问题的,大神认为是有问题的,有什么问题呢?你每次请求的接口或者地址,都在做描述,例如查询的时候用了query,新增的时候用了save,其实完全没有这个必要,我使用了get请求,就是查询.使用post请求,就是新增的请求,我的意图很明显,完全没有必要做描述,这就是为什么有了restful.

如何使用:

SpringMVC实现restful服务:

SpringMVC原生态的支持了REST风格的架构设计

所涉及到的注解:

---@RequestMapping
---@PathVariable
---@ResponseBody

HTTP相应状态码: 关于rest 接口开发和rest api接口开发的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 rest 接口开发的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于rest api接口开发、rest 接口开发的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。