系统接口设计url（系统接口设计逻辑）

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

本文目录一览：

• 1、接口设计时为什么把系统参数放在url后面
• 2、系统方案 - 设计一个 URL 短链服务
• 3、如何优雅的设计Restful API URL
• 4、软件测试之接口测试核心-URLamp;HTTP协议详解重磅来袭，转发收藏

接口设计时为什么把系统参数放在url后面

接口传输主要通过两种方式去传递，分别为get方式和post方式，其中post请求会吧参数放在请求体里面。所以url中是看不到参数的，所以你说的也就是get请求，这种方式是将参数放在了请求头里面，从而在url中可以看到，这样写目的主要两点：
1，准确来说也是中规则体现，毕竟任何东西都有自己规则
2，服务端可直接通过url获取请求参数，降低开发成本

系统方案 - 设计一个 URL 短链服务

短链接，通俗来说，就是将长的URL网址，通过程序计算等方式，转换为简短的网址字符串。

微博和Twitter都有140字数的限制，如果分享一个长网址，很容易就超出限制。

营销短信，字数的限制,当字数过长: 1.不美观 2.超出字符额外收费。

生成二维码的原始链接,当原始链接过长时,生成的二维码过于复杂,导致一些像素较低的手机无法扫描.

功能要求：

非功能性要求：

扩展要求：

可以使用 REST API 来公开我们服务的功能。以下可能是用于创建和删除 URL 的 API 的定义：

createURL (api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)

参数：

api_dev_key(string)：注册账号的API开发者密钥。除其他外，这将用于根据分配的配额限制用户。

original_url（字符串）：要缩短的原始 URL。

custom_alias（字符串）：URL 的可选自定义键。

user_name（字符串）：在编码中使用的可选用户名。

expire_date (string): 缩短 URL 的可选过期日期。

返回 ：（字符串）

成功插入会返回缩短的 URL；否则，它会返回错误代码。

deleteURL (api_dev_key, url_key)

其中“url_key”是一个字符串，表示要检索的缩短的 URL；成功删除会返回“已删除 URL”。

如何发现和防止滥用？恶意用户可以通过使用当前设计中的所有 URL 密钥使我们破产。为了防止滥用，我们可以通过他们的 api_dev_key 限制用户。每个 api_dev_key 可以限制为每个时间段内特定数量的 URL 创建和重定向（每个开发者密钥可以设置为不同的持续时间）。

结合储存数据设计：

数据库架构：

我们需要两张表：一张用于存储有关 URL 映射的信息，另一张用于创建短链接的用户数据。

应该使用什么样的数据库？由于我们预计存储数十亿行，并且我们不需要使用对象之间的关系——NoSQL 选择更容易扩展

在第 1 节的示例中，缩短的 URL 是“https://tinyurl.com/vzet59pa”。这个 URL 的最后八个字符构成了我们要生成的短链。讨论以下两种解决方案： 摘要算法、自增序列算法

方案一：摘要算法

这种算法,虽然会生成4个,但是仍然存在重复几率

方案二： 自增序列算法

设置 id 自增，一个 10进制 id 对应一个 62进制的数值，1对1，也就不会出现重复的情况。这个利用的就是低进制转化为高进制时，字符数会减少的特性。

第一种算法的好处就是简单好理解，永不重复。但是短码的长度不固定，随着 id 变大从一位长度开始递增。如果非要让短码长度固定也可以就是让 id 从指定的数字开始递增就可以了。百度短网址用的这种算法。

为了扩展我们的数据库，我们需要对其进行分区，以便它可以存储有关数十亿个 URL 的信息。因此，我们需要开发一种分区方案，将我们的数据划分并存储到不同的数据库服务器中。

一个基于范围的分区： 我们可以根据哈希键的第一个字母将 URL 存储在单独的分区中。因此，我们将所有以字母“A”（和“a”）开头的 URL 哈希键保存在一个分区中，将那些以字母“B”开头的 URL 哈希键保存在另一个分区中，依此类推。这种方法称为基于范围的分区。我们甚至可以将某些不太频繁出现的字母组合到一个数据库分区中。因此，我们应该开发一种静态分区方案，以始终以可预测的方式存储/查找 URL。

这种方法的主要问题是它可能导致数据库服务器不平衡。例如，我们决定将所有以字母“E”开头的 URL 放入 DB 分区，但后来我们意识到我们有太多以字母“E”开头的 URL。

另外基于散列的分区： 在这个方案中，我们获取我们正在存储的对象的散列。然后我们根据哈希计算要使用的分区。在我们的例子中，我们可以使用“键”或短链接的哈希值来确定我们存储数据对象的分区。

我们的散列函数会将 URL 随机分布到不同的分区中（例如，我们的散列函数总是可以将任何“键”映射到 [1…256] 之间的数字）。这个数字将代表我们存储对象的分区。

这种方法仍然会导致分区过载，这可以使用一致哈希解决。

可以缓存经常访问的 URL，结合缓存中间件例如 Memcached、redis，它可以存储完整的 URL 及其各自的哈希值。因此，应用服务器在访问后端存储之前，可以快速检查缓存是否具有所需的 URL。

我们应该有多少缓存内存？ 我们可以从每天 20% 的流量开始，根据客户的使用模式，我们可以调整我们需要多少缓存服务器。如上所述，我们需要 170GB 的内存来缓存 20% 的日常流量。由于现代服务器可以拥有 256GB 内存，我们可以轻松地将所有缓存放入一台机器中。或者，我们可以使用几个较小的服务器来存储所有这些热门 URL。

哪种缓存驱逐策略最适合我们的需求？ 当缓存已满，并且我们想用更新/更热的 URL 替换链接时，我们将如何选择？最近最少使用 (LRU) 可能是我们系统的合理策略。根据此政策，会首先丢弃最近最少使用的 URL，可以使用 Linked Hash Map 或类似的数据结构来存储我们的 URL 和哈希，这也将跟踪最近访问过的 URL。

如何更新每个缓存副本？ 每当缓存未命中时，我们的服务器就会访问后端数据库。每当发生这种情况时，我们都可以更新缓存并将新条目传递给所有缓存副本。每个副本都可以通过添加新条目来更新其缓存。如果副本已经有该条目，它可以简单地忽略它。

我们可以在系统的三个地方添加负载均衡层：

条目应该永远存在，还是应该被清除？如果达到用户指定的过期时间，链接会发生什么？

如果我们选择不断搜索过期链接来删除它们，这会给我们的数据库带来很大的压力。相反，我们可以慢慢删除过期链接并进行惰性清理。我们的服务会确保只删除过期的链接。

用户能否创建私有 URL 或允许一组特定用户访问 URL？

可以将权限级别（公共/私有）与数据库中的每个 URL 一起存储，还可以创建一个单独的表来存储有权查看特定 URL 的 UserID。如果用户没有权限并尝试访问 URL，可以发回错误 (HTTP 401)。鉴于我们将数据存储在像 Cassandra 这样的 NoSQL 宽列数据库中，表存储权限的键将是“哈希”（或 KGS 生成的“键”）。这些列将存储那些有权查看 URL 的用户的用户 ID。

如何优雅的设计Restful API URL

一个好的RESTful API，应该具备以下特征：
这个API应该是对浏览器友好的，能够很好地融入Web，而不是与Web格格不入。
1.浏览器是最常见和最通用的REST客户端。好的RESTful API应该能够使用浏览器+HTML完成所有的测试（不需要使用编程语言）。这样的API还可以很方便地使用各种自动化的Web功能测试、性能测试工具来做测试。Web前端应用（基于浏览器的RIA应用、移动App等等）也可以很方便地将多个RESTful API的功能组合起来，建造Mashup类的应用。
这个API中所包含的资源和对于资源的操作，应该是直观和容易理解的，并且符合HTTP协议的要求。
REST开发又被称作“面向资源的开发”，这说明对于资源的抽象，是设计RESTful API的核心内容。RESTful API建模的过程与面向对象建模类似，是以名词为核心的。这些名词就是资源，任何可命名的抽象概念都可以定义为一个资源。而HTTP协议并不是一种传输协议，它实际提供了一个操作资源的统一接口。对于资源的任何操作，都应该映射到HTTP的几个有限的方法（常用的有GET/POST/PUT/DELETE四个方法，还有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTful API建模的过程，可以看作是具有统一接口约束的面向对象建模过程。
按照HTTP协议的规定，GET方法是安全且幂等的，POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法），PUT、DELETE方法都是不安全但幂等的。将对资源的操作合理映射到这四个方法上面，既不过度使用某个方法（例如过度使用GET方法或POST方法），也不添加过多的操作以至于HTTP的四个方法不够用。
2.如果发现资源上的操作过多，以至于HTTP的方法不够用，应该考虑设计出更多的资源。设计出更多资源（以及相应的URI）对于RESTful API来说并没有什么害处。
这个API应该是松耦合的。
RESTful API的设计包括了三个循序渐进、由低到高的层次：资源抽象、统一接口、超文本驱动。正是这三个层次确保了RESTful API的松耦合性。
3.当设计面向互联网的API时，松耦合变成了一种“必须有”的强需求。紧耦合的API非常脆弱，一旦公布出去，服务器端和客户端都无法持续进化。尤其是服务器端，公布出去的接口根本不敢改，改了之后，几乎所有客户端应用立即无法正常工作。REST这种架构风格就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不展开了。感兴趣的读者可以参考《REST实战》。
这个API中所使用的表述格式应该是常见的通用格式
在RESTful API中，对于资源的操作，是通过在服务器端-客户端之间传递资源的表述来间接完成的。资源的表述可以有很多种格式，并且在响应和请求中的资源表述格式也会有所不同。GET/POST响应中的资源表述格式，常见的有HTML、XML、JSON；POST/PUT请求中的资源表述格式，常见的有标准的HTML表单参数、XML、JSON。
4.这些常见表述格式，处理起来非常容易，有大量的框架和库提供支持。所以除非有很合理的要求，通常不需要使用自定义的私有格式。
使用HTTP响应状态代码来表达各种出错情况
HTTP响应状态代码，是HTTP协议这个统一接口中用来表达出错情况的标准机制。响应状态代码分成两部分：status code和reason phase。两部分都是可定制的，也可以使用标准的status code，只定制reason phase。
5.如果一个所谓的“RESTful API”对于任何请求都返回200 OK响应，在响应的消息体中返回出错情况信息，这种做法显然不符合“确保操作语义的可见性”这个REST架构风格的基本要求。
这个API应该对于HTTP缓存是友好的
6.充分利用好HTTP缓存是RESTful API可伸缩性的根本。HTTP协议是一个分层的架构，从两端的user agent到origin server之间，可以插入很多中间组件。而在整个HTTP通信链条的很多位置，都可以设置缓存。HTTP协议内建有很好的缓存机制，可以分成过期模型和验证模型两套缓存机制。如果API设计者完全没有考虑过如何利用HTTP缓存，那么这个API的可伸缩性会有很多问题。

软件测试之接口测试核心-URLamp;HTTP协议详解重磅来袭，转发收藏

URL：统一资源定位符。

URI：统一资源标识符。

URL可以看作是URI的具体实现。

·protocol

·domain

·port

·path

·url parameters

示例：

https://ke.qq.com/course/317690?tuin=15945f87

协议，一般是指://之前的部分，表明通信双方所采用的通信协议。

协议：是指通信双方对于通信的数据所采用的数据格式、规程、含义等所作的约定。

对于协议，建议大家了解两个模型：OSI模型和TCP/IP模型。

从接口测试的角度来说，在不同的通信层可以通过不同的协议来实现接口的测试。

一般来说，应用层的协议是最接近用户，最容易实现的。

常见的应用层协议有：

http

https http+ssl

ftp

ssh

smtp

pop3

mysql

oracle

MS SQL

是指://之后的服务器地址。域名可以是真实的服务器机器的机器名、IP地址、虚拟的域名。

示例：

www.baidu.com

ke.qq.com

192.168.1.100

是指通过冒号连接在域名之后的数字。

端口：0--65535

端口是由服务器自身来进行设定的，是服务器用来发布服务，监听客户端的请求的。

如果服务器所设置的监听端口是所提供服务的通信协议的默认通信端口，则用户在访问服务器时，可以省略端口。

常见的协议及其默认的通信端口：

http 80

https 443

ftp 21

ssh 22

smtp 25

pop3 110

mysql 3306

oracle 1521

MS SQL 1433

是指在端口之后的所有内容。

一般来说path是指我们要访问的资源or服务在服务器的容器下的路径。

通常path就会和接口的功能直接挂钩。

URL地址参数也是属于PATH的一部分。

url地址参数是指通过问号的方式连接在path之后的部分。

url地址参数采用的是键值对的方式传递参数值，多个键值对之间使用作为连接符。

http协议：HypeText Transfer Protocol，超文本传输协议。

目前来说，http协议是绝大多数服务首选的通信协议。

http协议是一种基于request（请求）和response（响应）的协议。

这就意味着http协议是分为两个部分：

·http request：http请求，是用来定义请求的发送者应该如何去组织数据。

·http response：http响应，是用来定义请求的处理者应该如何去组织返回的数据。

http请求是由三个部分构成：

请求行是指请求数据包中的第一行内容。

示例：GET /phpwind/ HTTP/1.1

一般来说，请求行中包含以下信息：

所有的http请求都必须有请求方法，如果没有指定，则默认为get方法。

常见的请求方法有：get、post、put、patch、delete、options、trace、header等。

接口使用何种请求方法，和测试没有关系，只和设计、开发有关系。

get和post的区别：

请求路径就是指URL中的路径部分，包含url地址参数。

请求头是指请求数据包中从第二行开始到第一个空行截止的所有内容。

请求头是客户端用来和服务器进行交互信息、控制信息的交互的，通常和业务本身是没有关系。

请求头是键值对应的。

标准的请求头都是有其特殊的含义和作用的。

比较常用的请求头：

· User-Agent ：简称UA，客户端用来告知服务器，客户端的环境信息。

PS：服务器通常会根据该信息头来判断客户请求的来源。

session和cookie的维持和该请求头有关（一致性）。

· Content-Type ：如果请求body中有数据，则该信息一定要添加。

PS：

·该信息头是用来告知服务器，请求主体中的数据的数据组织格式。

常见的组织格式有：

键值对格式：

示例： aaa=1bbb=2

混合表单格式，多用于文件上传类型的接口。boundary表示分隔符，实际的请求主体中的分隔符比请求头中的分隔符要多"--"。

表示发送的是json格式的数据。

示例：{"aaa":1,"bbb":2}

·请求中具体使用何种格式的数据组织格式，由接口本身决定。

·要避免在全局请求头中使用Content-Type。

·c ookie、token ：状态相关的信息头。一般来说cookie不用额外处理。

token这样的信息头基本上都需要做关联处理。

是指请求数据包中从第一个空行开始到最后的所有内容。

·请求主体一般都是和业务相关的，是客户端发送给服务器的业务数据。

·请求主体中的数据是有特定组织格式（Content-Type），由开发决定，和测试无关。

·查看请求数据，建议通过raw格式。。尤其是进行调试的时候。

一般来说http响应也是分为三个部分。

·response line：响应行

·response headers：响应头

·response body：响应主体

响应行是指响应数据包中的第一行内容。

通常来说包含下列信息。

示例：

HTTP/1.1 200 OK

响应代码，又叫status、status code，状态、状态码。

响应代码是服务器用来告知客户端，服务器对于请求的通信逻辑层面的处理结果。

响应代码是三位长度的数字，根据首位数字的不同，可以分为5类。

1xx：表示连接建立过程中的交互、控制信息。

2xx：表示服务器处理成功，典型就是200.

3xx：表示重定向。

PS：1xx、2xx、3xx都表示请求成功，即服务器正常工作。

4xx：表示客户端错误。

如：400、401、403、404、405

5xx：表示服务器错误。

如：500、502、501

PS:在接口测试时，不论出现4xx、5xx都表示脚本出错了。

脚本出错有两种情况：

·协议层面：http请求的格式组装问题。

·业务层面：业务相关的数据不合法导致。

PS：一旦出错，我们需要做的就是去对比成功的请求数据包（包含头和body）和失败的请求数据包。

响应头是指响应数据包中从第二行开始到第一个空行截止的部分。

响应头是服务器用来告知客户端，服务器的一些交互、控制信息。

比较常见的：

set-cookie：是服务器用来返回cookie给客户端。

响应主体，是指响应数据包中从第一个空行开始到最后的所有内容。

·响应主体有可能是压缩、编码的，有些测试工具会自动处理，有些需要编程处理。

·响应主体一般都是服务器对于接口的处理结果，和业务相关。

这就意味着我们要判断一个接口的功能是否正确，或者要提取服务器返回的数据，通常都要对响应主体进行操作。

关于系统接口设计url和系统接口设计逻辑的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 系统接口设计url的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于系统接口设计逻辑、系统接口设计url的信息别忘了在本站进行查找喔。

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