设计网站的URL时应该注意啥问题？

Posted 2023-05-12

1、URL应保持规范、简单。

创建具有良好描述性、规范、简单的url，有利于用户更方便的记忆和判断网页的内容，也有利于搜索引擎更有效的抓取您的网站；

2、URL尽量短

长URL不仅不美观，用户还很难从中获取额外有用的信息。另一方面，短url还有助于减小页面体积，加快网页打开速度，提升用户体验；

3、减少特殊字符

URL中应该去掉不能被系统自动识别为url的字符，例如：竖线、分号。这样的url在聊天软件中都不方便直接点击进去。另外，建议通过服务器的rewrite来优化url，让url中减少'？'和'&'的出现。

4、URL针对SEO的优化

关于SEO的朋友还可以关注下，在《百度搜索引擎优化指南2.0》中提到了以下网站设计URL时注意的问题，相关链接：http://zhanzhang.baidu.com/college/documentinfo?id=193&page=3

参考技术A

1、URL应保持规范、简单。

创建具有良好描述性、规范、简单的url，有利于用户更方便的记忆和判断网页的内容，也有利于搜索引擎更有效的抓取您的网站；

2、URL尽量短

长URL不仅不美观，用户还很难从中获取额外有用的信息。另一方面，短url还有助于减小页面体积，加快网页打开速度，提升用户体验；

3、减少特殊字符

URL中应该去掉不能被系统自动识别为url的字符，例如：竖线、分号。这样的url在聊天软件中都不方便直接点击进去。另外，建议通过服务器的rewrite来优化url，让url中减少'？'和'&'的出现。

4、URL针对SEO的优化

关于SEO的朋友还可以关注下，在《百度搜索引擎优化指南2.0》中提到了以下网站设计URL时注意的问题，相关链接：http://zhanzhang.baidu.com/college/documentinfo?id=193&page=3

参考技术B 个人比较建议Web API使用RESTful设计，REST概念分离了API结构和逻辑资源，通过Http方法GET, DELETE, POST 和 PUT来操作资源。
下面是进行RESTful Web API十个建议:
1.使用名词而不是动词
Resource
资源
GET
读 POST
创建 PUT
修改 DELETE
/cars 返回 cars集合 创建新的资源 批量更新cars 删除所有cars
/cars/711 返回特定的car 该方法不允许(405) 更新一个指定的资源 擅长指定资源
不要使用：
/getAllCars
/createNewCar
/deleteAllRedCars

2.Get方法和查询参数不应该涉及状态改变
使用PUT, POST 和DELETE 方法 而不是 GET 方法来改变状态，不要使用GET 进行状态改变:
GET /users/711?activate
GET /users/711/activate
3.使用复数名词
不要混淆名词单数和复数，为了保持简单，只对所有资源使用复数。
/cars 而不是 /car
/users 而不是 /user
/products 而不是 /product
/settings 而部署 /setting

4. 使用子资源表达关系
如果一个资源与另外一个资源有关系，使用子资源：
GET /cars/711/drivers/ 返回 car 711的所有司机
GET /cars/711/drivers/4 返回 car 711的4号司机

5.使用Http头声明序列化格式
在客户端和服务端，双方都要知道通讯的格式，格式在HTTP-Header中指定
Content-Type 定义请求格式
Accept 定义系列可接受的响应格式

6.使用HATEOAS
Hypermedia as the Engine of Application State 超媒体作为应用状态的引擎，超文本链接可以建立更好的文本浏览
7.为集合提供过滤 排序 选择和分页等功能
Filtering过滤:
使用唯一的查询参数进行过滤：
GET /cars?color=red 返回红色的cars
GET /cars?seats<=2 返回小于两座位的cars集合
Sorting排序:
允许针对多个字段排序
GET /cars?sort=-manufactorer,+model
这是返回根据生产者降序和模型升序排列的car集合
Field selection
移动端能够显示其中一些字段，它们其实不需要一个资源的所有字段，给API消费者一个选择字段的能力，这会降低网络流量，提高API可用性。
GET /cars?fields=manufacturer,model,id,color

8.版本化你的API
使得API版本变得强制性，不要发布无版本的API，使用简单数字，避免小数点如2.5.
一般在Url后面使用?v
/blog/api/v1

9. 使用Http状态码处理错误
如果你的API没有错误处理是很难的，只是返回500和出错堆栈不一定有用
Http状态码提供70个出错，充分利用。
10.允许覆盖http方法
一些代理只支持POST 和 GET方法， 为了使用这些有限方法支持RESTful API，需要一种办法覆盖http原来的方法。
使用订制的HTTP头 X-HTTP-Method-Override 来覆盖POST 方法. 参考技术C 个人比较建议Web API使用RESTful设计，REST概念分离了API结构和逻辑资源，通过Http方法GET, DELETE, POST 和 PUT来操作资源。
下面是进行RESTful Web API十个建议:
1.使用名词而不是动词
Resource
资源
GET
读 POST
创建 PUT
修改 DELETE
/cars 返回 cars集合 创建新的资源 批量更新cars 删除所有cars
/cars/711 返回特定的car 该方法不允许(405) 更新一个指定的资源 擅长指定资源
不要使用：
/getAllCars
/createNewCar
/deleteAllRedCars

2.Get方法和查询参数不应该涉及状态改变
使用PUT, POST 和DELETE 方法 而不是 GET 方法来改变状态，不要使用GET 进行状态改变:
GET /users/711?activate
GET /users/711/activate
3.使用复数名词
不要混淆名词单数和复数，为了保持简单，只对所有资源使用复数。
/cars 而不是 /car
/users 而不是 /user
/products 而不是 /product
/settings 而部署 /setting

4. 使用子资源表达关系
如果一个资源与另外一个资源有关系，使用子资源：
GET /cars/711/drivers/ 返回 car 711的所有司机
GET /cars/711/drivers/4 返回 car 711的4号司机

5.使用Http头声明序列化格式
在客户端和服务端，双方都要知道通讯的格式，格式在HTTP-Header中指定
Content-Type 定义请求格式
Accept 定义系列可接受的响应格式

6.使用HATEOAS
Hypermedia as the Engine of Application State 超媒体作为应用状态的引擎，超文本链接可以建立更好的文本浏览
7.为集合提供过滤 排序 选择和分页等功能
Filtering过滤:
使用唯一的查询参数进行过滤：
GET /cars?color=red 返回红色的cars
GET /cars?seats<=2 返回小于两座位的cars集合
Sorting排序:
允许针对多个字段排序
GET /cars?sort=-manufactorer,+model
这是返回根据生产者降序和模型升序排列的car集合
Field selection
移动端能够显示其中一些字段，它们其实不需要一个资源的所有字段，给API消费者一个选择字段的能力，这会降低网络流量，提高API可用性。
GET /cars?fields=manufacturer,model,id,color

8.版本化你的API
使得API版本变得强制性，不要发布无版本的API，使用简单数字，避免小数点如2.5.
一般在Url后面使用?v
/blog/api/v1

9. 使用Http状态码处理错误
如果你的API没有错误处理是很难的，只是返回500和出错堆栈不一定有用
Http状态码提供70个出错，充分利用。
10.允许覆盖http方法
一些代理只支持POST 和 GET方法， 为了使用这些有限方法支持RESTful API，需要一种办法覆盖http原来的方法。
使用订制的HTTP头 X-HTTP-Method-Override 来覆盖POST 方法.

作为开发人员，我应该啥时候测试我的网站？

【中文标题】作为开发人员，我应该啥时候测试我的网站？

【英文标题】：As a developer, when should I test my website?作为开发人员，我应该什么时候测试我的网站？

【发布时间】：2017-04-29 01:38:42

【问题描述】：

在我发布我的网站后，我想在几个浏览器中对其进行测试。此外，当新的 Android 设备问世时，我也会去那里看看。我很好奇我应该使用哪些其他里程碑来指导我的网站测试计划（例如，当新版本的 Chrome 发布时，我是否应该优先考虑在该新版本中进行测试？）

正如背景：我的网站有很高的质量要求，需要在很多不同的浏览器中工作。

提前致谢！

【问题讨论】：

常识。当有新的东西出现时，如果您担心它，请对其进行测试。但是很多浏览器使用相同的 JS 引擎和东西，所以不同的设备并不一定意味着不同的浏览器

使用一些在线网站，在不同的环境中提供数百张截图。

【参考方案1】：

在新版本的 chrome/Firefox 中网站崩溃是非常罕见的。

when a new Android device comes out I'll take a look there also

你的意思是当新版本的安卓或新的流行设备发布时。

所有浏览器都有相同的浏览器并且所有工作都相同。再次，在新版本的 android 中很难让网站崩溃。

为了进行测试，您可以在线获取您网站在不同环境中的许多屏幕截图。我用过，测试效果不错。

例如，您的网站在 Opera 中崩溃了，您可以通过在屏幕截图中查看问题来轻松修复它。

【参考方案2】：

说到底，一切都是为了钱。每个新的浏览器/设备都有望获得一定的市场份额。基于此，您可以计算如果此设备/浏览器无法正确呈现您的页面，您将损失多少钱。您还知道您需要支付多少费用来跟踪新的浏览器/设备并对其进行测试（通常是测试版）

我认为没有任何其他准则。您监控市场并决定要支持哪些浏览器/设备。如果很重要，那么在 beta 版本上进行测试也是明智之举（这会告诉您预期会发生什么，安排多少时间来进行最终测试和修复）