|
|
## IDEA 好用的插件推荐
|
|
|
Vuesion Theme 主题
|
|
|
Atom Material ICons 图标插件 解决在拖动滚动条或是鼠标中键滚屏时有点卡顿问题
|
|
|
File Expander 它能在Idea里直接打开Jar包，并且反编译代码查看。甚至于能打开tar.gz，zip等压缩格式。
|
|
|
GitToolBox 他能在项目上提示你还有多少文件没提交，远程还有多少文件没更新下来。还能在每一行代码上提示上次提交的时间。查版本提交问题的时候尤其方便。
|
|
|
Maven Helper 排查Jar包依赖等问题用这个简直是神器。这个插件也提供了一些其他的快捷命令，右键直接唤起maven命令，颇为方便。
|
|
|
Translation 实时进行精准快速的翻译，自动识别语言。
|
|
|
arthas idea Arthas是阿里开源的一款强大的java在线诊断工具，使用起来非常方便，进入代码片段，选择你要诊断的类或者方法上面，右击打开Arthas命令，选择一项，即可自动生成命令，省去你敲打命令的时间。
|
|
|
Search In Repository 直接把中央仓库的查找集成到了Idea里面。你只需要打开这款插件，输入jar包的名字或者gav关键字，就能查到到这个jar包所有的版本，然后可以直接复制gav坐标。
|
|
|
VisualGC Idea堆栈的可视化工具，和Idea深度集成。直接显示所有进程，双击即可打开JVM的堆栈可视化界面。堆栈和垃圾收集情况一目了然！
|
|
|
Zoolytic idea里面直接可以看zookeeper的节点信息
|
|
|
|
|
|
## 接口设计规范
|
|
|
|
|
|
- 对URL使用kebab-case（短横线小写隔开形式）
|
|
|
> 如果你想要获得订单列表。<br/>
|
|
|
> 错误：/systemOrders或/system_orders <br/>
|
|
|
> 正确：/system-orders
|
|
|
- 参数使用camelCase（驼峰形式）
|
|
|
> 如果想从一个特定的商店购买产品<br/>
|
|
|
> 错误：/system-orders/{order_id} 或者 /system-orders/{OrderId}<br/>
|
|
|
> 正确：/system-orders/{orderId}
|
|
|
- 指向集合的复数名称
|
|
|
> 如果你想获得系统的所有用户。<br/>
|
|
|
> 错误：GET /user 或者 GET /User<br/>
|
|
|
> 正确：GET /users
|
|
|
- URL以集合开始，以标识符结束(REST接口专用)
|
|
|
> 如果要保持概念的单一性和一致性。<br/>
|
|
|
> 错误：GET /shops/:shopId/category/:categoryId/price</br>
|
|
|
> 正确：GET /shops/:shopId/或GET /category/:categoryId
|
|
|
- 让动词远离你的资源URL(REST接口专用)
|
|
|
> 不要在URL中使用动词来表达你的意图。相反，使用适当的HTTP方法来描述操作。<br/>
|
|
|
> 错误：POST /updateuser/{userId} 或 GET /getusers<br/>
|
|
|
> 正确 PUT /user/{userId}
|
|
|
- 对非资源URL使用动词
|
|
|
> 如果你有一个端点，它只返回一个操作。在这种情况下，你可以使用动词。例如，如果你想要向用户重新发送警报。<br/>
|
|
|
> POST /alarm/245743/resend <br/>
|
|
|
> 这些不是我们的CRUD操作。相反，它们被认为是在我们的系统中执行特定工作的函数。
|
|
|
- JSON属性使用camelCase驼峰形式
|
|
|
> 如果你正在构建一个请求体或响应体为JSON的系统，那么属性名应该使用驼峰大小写。<br/>
|
|
|
> 错误：{ user_name: "Mohammad Faisal", user_id: "1"}<br/>
|
|
|
> 正确：{ userName: "Mohammad Faisal", userId: "1"}
|
|
|
- 监控
|
|
|
> RESTful HTTP服务必须实现/health和/version和/metricsAPI端点。他们将提供以下信息。<br/>
|
|
|
> /health: 用200 OK状态码响应对/health的请求。<br/>
|
|
|
> /version: 用版本号响应对/version的请求。<br/>
|
|
|
> /metrics: 这个端点将提供各种指标，如平均响应时间。<br/>
|
|
|
> 也强烈推荐使用/debug和/status端点。
|
|
|
- 不要使用table_name作为资源名(不是特别建议)
|
|
|
> 不要只使用表名作为资源名。从长远来看，这种懒惰是有害的。<br/>
|
|
|
> 错误：product_order<br/>
|
|
|
> 正确：product-orders<br/>
|
|
|
- 使用简单序数作为版本
|
|
|
> 始终对API使用版本控制，并将其向左移动，使其具有最大的作用域。版本号应该是v1，v2等等。<br/>
|
|
|
> 应该：http://api.domain.com/v1/shops/3/products <br/>
|
|
|
> 始终在API中使用版本控制，因为如果API被外部实体使用，更改端点可能会破坏它们的功能。<br/>
|
|
|
- 在你的响应体中包括总资源数
|
|
|
> 如果API返回一个对象列表，则响应中总是包含资源的总数。你可以为此使用total属性。<br/>
|
|
|
> 错误：{ users: [...]}<br/>
|
|
|
> 正确：{ users: [...], total: 34 }<br/>
|
|
|
- 接受limit和offset参数(在定义业务接口中用到,且一定要进行校验)
|
|
|
> 在GET操作中始终接受limit和offset参数。<br/>
|
|
|
> 正确：GET /shops?offset=5&limit=5<br/>
|
|
|
> 这是因为它对于前端的分页是必要的。<br/>
|
|
|
- 获取字段查询参数(用于对外暴露的查询接口,严格限制数据权限)
|
|
|
> 返回的数据量也应该考虑在内。添加一个fields参数，只公开API中必需的字段。<br/>
|
|
|
> 只返回商店的名称，地址和联系方式。<br/>
|
|
|
> GET /shops?fields=id,name,address,contact<br/>
|
|
|
> 在某些情况下，它还有助于减少响应大小。<br/>
|
|
|
- 不要在URL中通过认证令牌
|
|
|
> 这是一种非常糟糕的做法，因为url经常被记录，而身份验证令牌也会被不必要地记录。<br/>
|
|
|
> 错误：GET /shops/123?token=some_kind_of_authenticaiton_token<br/>
|
|
|
> 正确：通过头部传递它们 - Authorization: Bearer xxxxxx, Extra yyyyy<br/>
|
|
|
> 此外，授权令牌应该是短暂有效期的。<br/>
|
|
|
- 验证内容类型
|
|
|
> 服务器不应该假定内容类型。例如，如果你接受application/x-www-form-urlencoded，那么攻击者可以创建一个表单并触发一个简单的POST请求。<br/>
|
|
|
> 因此，始终验证内容类型，如果你想使用默认的内容类型，请使用：content-type: application/json<br/>
|
|
|
- 对CRUD函数使用HTTP方法（REST）
|
|
|
> HTTP方法用于解释CRUD功能。<br/>
|
|
|
> GET：检索资源的表示形式。<br/>
|
|
|
> POST：创建新的资源和子资源。<br/>
|
|
|
> PUT：更新现有资源。<br/>
|
|
|
> PATCH：更新现有资源，它只更新提供的字段，而不更新其他字段。<br/>
|
|
|
> DELETE：删除已存在的资源。<br/>
|
|
|
- 在嵌套资源的URL中使用关系
|
|
|
> GET /shops/2/products：从shop 2获取所有产品的列表。<br/>
|
|
|
> GET /shops/2/products/31：获取产品31的详细信息，产品31属于shop 2。<br/>
|
|
|
> DELETE /shops/2/products/31：应该删除产品31，它属于商店2。<br/>
|
|
|
> PUT /shops/2/products/31：应该更新产品31的信息，只在resource-URL上使用PUT，而不是集合。<br/>
|
|
|
> POST /shops：应该创建一个新的商店，并返回创建的新商店的详细信息。在集合url上使用POST。<br/>
|
|
|
- CORS（跨源资源共享）
|
|
|
> 一定要为所有面向公共的API支持CORS（跨源资源共享）头部。<br/>
|
|
|
> 考虑支持CORS允许的“*”来源，并通过有效的OAuth令牌强制授权。<br/>
|
|
|
> 避免将用户凭证与原始验证相结合。<br/>
|
|
|
- 安全
|
|
|
> 在所有端点、资源和服务上实施HTTPS（tls加密）。<br/>
|
|
|
> 强制并要求所有回调url、推送通知端点和webhooks使用HTTPS。<br/>
|
|
|
- 错误
|
|
|
> 当客户端向服务发出无效或不正确的请求，或向服务传递无效或不正确的数据，而服务拒绝该请求时，就会出现错误，或者更具体地说，出现服务错误。<br/>
|
|
|
> 包括无效的身份验证凭证、不正确的参数、未知的版本id等。<br/>
|
|
|
> 当由于一个或多个服务错误而拒绝客户端请求时，一定要返回4xx HTTP错误代码。<br/>
|
|
|
> 考虑处理所有属性，然后在单个响应中返回多个验证问题。<br/>
|
|
|
- 黄金法则
|
|
|
> 扁平比嵌套好。
|
|
|
> 简单胜于复杂。
|
|
|
> 字符串比数字好。
|
|
|
> 一致性比定制更好。 |
