资讯频道 → Web前端
阅读更多

14顶
0踩

Web前端

转载新闻 RESTful API 设计最佳实践

2013-06-13 19:26 by 副主编 WnouM 评论(5) 有27099人浏览
RESTful API APP 设计
背景

目前互联网上充斥着大量的关于RESTful API（为了方便，后面API和RESTful API 一个意思）如何设计的文章，然而却没有一个“万能”的设计标准：如何鉴权？API格式如何？你的API是否应该加入版本信息？当你开始写一个app的时候，特别是后端模型部分已经写完的时候，你不得不殚精竭虑的设计和实现自己app的public API部分。因为一旦发布，对外发布的API将会很难改变。

在给SupportedFu设计API的时候，我试图以实用的角度来解决上面提到的问题。我希望可以设计出容易使用，容易部署，并且足够灵活的API，本文因此而生。

API设计的基本要求

网上的很多关于API设计的观点都十分”学院派“，它们也许更有理论基础，但是有时却和现实世界脱轨（因此我是自由派）。所以我这篇文章的目标是从实践的角度出发，给出当前网络应用的API设计最佳实践（当然，是我认为的最佳了~），如果觉得不合适，我不会遵从标准。当然作为设计的基础，几个必须的原则还是要遵守的：

  1. 当标准合理的时候遵守标准。
  2. API应该对程序员友好，并且在浏览器地址栏容易输入。
  3. API应该简单，直观，容易使用的同时优雅。
  4. API应该具有足够的灵活性来支持上层ui。
  5. API设计权衡上述几个原则。
需要强调的是：API的就是程序员的UI，和其他UI一样，你必须仔细考虑它的用户体验！

使用RESTful URLs 和action

虽然前面我说没有一个万能的API设计标准。但确实有一个被普遍承认和遵守：RESTfu设计原则。它被Roy Felding提出（在他的”基于网络的软件架构“论文中第五章）。而REST的核心原则是将你的API拆分为逻辑上的资源。这些资源通过http被操作（GET ,POST,PUT,DELETE）。

那么我应该如何拆分出这些资源呢？

显然从API用户的角度来看，”资源“应该是个名词。即使你的内部数据模型和资源已经有了很好的对应，API设计的时候你仍然不需要把它们一对一的都暴露出来。这里的关键是隐藏内部资源，暴露必需的外部资源。

在SupportFu里，资源是 ticket、user、group。

一旦定义好了要暴露的资源，你可以定义资源上允许的操作，以及这些操作和你的API的对应关系：

  • GET /tickets # 获取ticket列表
  • GET /tickets/12 # 查看某个具体的ticket
  • POST /tickets # 新建一个ticket
  • PUT /tickets/12 # 更新ticket 12.
  • DELETE /tickets/12 #删除ticekt 12
可以看出使用REST的好处在于可以充分利用http的强大实现对资源的CURD功能。而这里你只需要一个endpoint：/tickets,再没有其他什么命名规则和url规则了，cool！

这个endpoint的单数复数

一个可以遵从的规则是：虽然看起来使用复数来描述某一个资源实例看起来别扭，但是统一所有的endpoint，使用复数使得你的URL更加规整。这让API使用者更加容易理解，对开发者来说也更容易实现。

如何处理关联？关于如何处理资源之间的管理REST原则也有相关的描述：

  • GET /tickets/12/messages- Retrieves list of messages for ticket #12
  • GET /tickets/12/messages/5- Retrieves message #5 for ticket #12
  • POST /tickets/12/messages- Creates a new message in ticket #12
  • PUT /tickets/12/messages/5- Updates message #5 for ticket #12
  • PATCH /tickets/12/messages/5- Partially updates message #5 for ticket #12
  • DELETE /tickets/12/messages/5- Deletes message #5 for ticket #12

其中，如果这种关联和资源独立，那么我们可以在资源的输出表示中保存相应资源的endpoint。然后API的使用者就可以通过点击链接找到相关的资源。如果关联和资源联系紧密。资源的输出表示就应该直接保存相应资源信息。（例如这里如果message资源是独立存在的，那么上面 GET /tickets/12/messages就会返回相应message的链接；相反的如果message不独立存在，他和ticket依附存在，则上面的API调用返回直接返回message信息）

不符合CURD的操作

对这个令人困惑的问题，下面是一些解决方法：

  • 重构你的行为action。当你的行为不需要参数的时候，你可以把active对应到activated这个资源，（更新使用patch）.
  • 以子资源对待。例如:GitHub上，对一个gists加星操作：PUT /gists/:id/star 并且取消星操作：DELETE /gists/:id/star.
  • 有时候action实在没有难以和某个资源对应上例如search。那就这么办吧。我认为API的使用者对于/search这种url也不会有太大意见的（毕竟他很容易理解）。只要注意在文档中写清楚就可以了。
  • 永远使用SSL
毫无例外，永远都要使用SSL。你的应用不知道要被谁，以及什么情况访问。有些是安全的，有些不是。使用SSL可以减少鉴权的成本：你只需要一个简单的令牌（token）就可以鉴权了，而不是每次让用户对每次请求签名。

值得注意的是：不要让非SSL的url访问重定向到SSL的url。

文档

文档和API本身一样重要。文档应该容易找到，并且公开（把它们藏到pdf里面或者存到需要登录的地方都不太好）。文档应该有展示请求和输出的例子：或者以点击链接的方式或者通过curl的方式（请见openstack的文档）。如果有更新（特别是公开的API），应该及时更新文档。文档中应该有关于何时弃用某个API的时间表以及详情。使用邮件列表或者博客记录是好方法。

版本化

在API上加入版本信息可以有效的防止用户访问已经更新了的API，同时也能让不同主要版本之间平稳过渡。关于是否将版本信息放入url还是放入请求头有过争论：API version should be included in the URL or in a header. 学术界说它应该放到header里面去，但是如果放到url里面我们就可以跨版本的访问资源了。。（参考openstack）。

strip使用的方法就很好：它的url里面有主版本信息，同时请求头俩面有子版本信息。这样在子版本变化过程中url的稳定的。变化有时是不可避免的，关键是如何管理变化。完整的文档和合理的时间表都会使得API使用者使用的更加轻松。

结果过滤，排序，搜索：

url最好越简短越好，和结果过滤，排序，搜索相关的功能都应该通过参数实现(并且也很容易实现)。

过滤：为所有提供过滤功能的接口提供统一的参数。例如：你想限制get /tickets 的返回结果:只返回那些open状态的ticket–get /tickektsstate=open这里的state就是过滤参数。

排序：和过滤一样，一个好的排序参数应该能够描述排序规则，而不业务相关。复杂的排序规则应该通过组合实现：

  • GET /ticketssort=-priority- Retrieves a list of tickets in descending order of priority
  • GET /ticketssort=-priority,created_at- Retrieves a list of tickets in descending order of priority. Within a specific priority, older tickets are ordered first
这里第二条查询中，排序规则有多个rule以逗号间隔组合而成。

搜索：有些时候简单的排序是不够的。我们可以使用搜索技术（ElasticSearch和Lucene）来实现（依旧可以作为url的参数）。

  • GET /ticketsq=return&state=open&sort=-priority,created_at- Retrieve the highest priority open tickets mentioning the word ‘return’
对于经常使用的搜索查询，我们可以为他们设立别名,这样会让API更加优雅。例如： 

get /ticketsq=recently_closed -> get /tickets/recently_closed.


限制API返回值的域

有时候API使用者不需要所有的结果，在进行横向限制的时候（例如值返回API结果的前十项）还应该可以进行纵向限制。并且这个功能能有效的提高网络带宽使用率和速度。可以使用fields查询参数来限制返回的域例如： 

GET /ticketsfields=id,subject,customer_name,updated_at&state=open&sort=-updated_at


更新和创建操作应该返回资源

PUT、POST、PATCH 操作在对资源进行操作的时候常常有一些副作用：例如created_at,updated_at 时间戳。为了防止用户多次的API调用（为了进行此次的更新操作），我们应该会返回更新的资源（updated representation.）例如：在POST操作以后，返回201 created 状态码，并且包含一个指向新资源的url作为返回头

是否需要 “HATEOAS“

网上关于是否允许用户创建新的url有很大的异议（注意不是创建资源产生的url）。为此REST制定了HATEOAS来描述了和endpoint进行交互的时候，行为应该在资源的metadata返回值里面进行定义。（译注：作者这里认为HATEOAS还不算成熟，读者感兴趣可以自己去原文查看）

只提供json作为返回格式

现在开始比较一下XML和json了。XML即冗长，难以阅读，又不适合各种编程语言解析。当然XML有扩展性的优势，但是如果你只是将它来对内部资源串行化，那么他的扩展优势也发挥不出来。很多应用（youtube,twitter,box）都已经开始抛弃XML了，我也不想多费口舌。给了google上的趋势图吧：

当然如果的你使用用户里面企业用户居多，那么可能需要支持XML。如果是这样的话你还有另外一个问题：你的http请求中的media类型是应该和accept 头同步还是和url？为了方便（browser explorability）,应该是在url中(用户只要自己拼url就好了)。如果这样的话最好的方法是使用.xml或者.json的后缀。

命名方式？

是蛇形命令（下划线和小写）还是驼峰命名？如果使用json那么最好的应该是遵守JAVASCRIPT的命名方法-也就是说骆驼命名法。如果你正在使用多种语言写一个库，那么最好按照那些语言所推荐的，java，c#使用骆驼，python，ruby使用snake。

个人意见：我总觉得蛇形命令更好使一些，当然这没有什么理论的依据。有人说蛇形命名读起来更快，能达到20%，也不知道真假http://ieeexplore.ieee.org/xpl/articleDetails.jsptp=&arnumber=5521745

默认使用pretty print格式，使用gzip

只是使用空格的返回结果从浏览器上看总是觉得很恶心(一大坨有没有？～)。当然你可以提供url上的参数来控制使用“pretty print”，但是默认开启这个选项还是更加友好。格外的传输上的损失不会太大。相反你如果忘了使用gzip那么传输效率将会大大减少，损失大大增加。想象一个用户正在debug那么默认的输出就是可读的-而不用将结果拷贝到其他什么软件中在格式化-是想起来就很爽的事，不是么？

下面是一个例子: 

$ curl https://API.github.com/users/veesahni > with-whitespace.txt
$ ruby -r json -e 'puts JSON JSON.parse(STDIN.read)' < with-whitespace.txt > without-whitespace.txt
$ gzip -c with-whitespace.txt > with-whitespace.txt.gz
$ gzip -c without-whitespace.txt > without-whitespace.txt.gz


输出如下： 

without-whitespace.txt- 1252 bytes
with-whitespace.txt- 1369 bytes
without-whitespace.txt.gz- 496 bytes
with-whitespace.txt.gz- 509 bytes


在上面的例子中，多余的空格使得结果大小多出了8.5%（没有使用gzip），相反只多出了2.6%。据说：twitter使用gzip之后它的streaming API传输减少了80%（link:https://dev.twitter.com/blog/announcing-gzip-compression-streaming-APIs）.

只在需要的时候使用“envelope”

很多API象下面这样返回结果： 

{
  "data" : {
    "id" : 123,
    "name" : "John"
  }
}


理由很简单：这样做可以很容易扩展返回结果，你可以加入一些分页信息，一些数据的元信息等－这对于那些不容易访问到返回头的API使用者来说确实有用，但是随着“标准”的发展（cors和http://tools.ietf.org/html/rfc5988#page-6都开始被加入到标准中了），我个人推荐不要那么做。

何时使用envelope？

有两种情况是应该使用envelope的。如果API使用者确实无法访问返回头，或者API需要支持交叉域请求（通过jsonp）。
jsonp请求在请求的url中包含了一个callback函数参数。如果给出了这个参数，那么API应该返回200，并且把真正的状态码放到返回值里面（包装在信封里），例如： 

callback_function({
  status_code: 200,
  next_page: "https://..",
  response: {
    ... actual JSON response body ... 
  }
})


同样为了支持无法方法返回头的API使用者，可以允许envelope=true这样的参数。

在post,put,patch上使用json作为输入

如果你认同我上面说的，那么你应该决定使用json作为所有的API输出格式，那么我们接下来考虑考虑API的输入数据格式。
很多的API使用url编码格式：就像是url查询参数的格式一样：单纯的键值对。这种方法简单有效，但是也有自己的问题：它没有数据类型的概念。这使得程序不得不根据字符串解析出布尔和整数,而且还没有层次结构–虽然有一些关于层次结构信息的约定存在可是和本身就支持层次结构的json比较一下还是不很好用。

当然如果API本身就很简单，那么使用url格式的输入没什么问题。但对于复杂的API你应该使用json。或者干脆统一使用json。
注意使用json传输的时候，要求请求头里面加入：Content-Type：applicatin/json.否则抛出415异常（unsupported media type）。

分页

分页数据可以放到“信封”里面，但随着标准的改进，现在我推荐将分页信息放到link header里面：http://tools.ietf.org/html/rfc5988#page-6。

使用link header的API应该返回一系列组合好了的url而不是让用户自己再去拼。这点在基于游标的分页中尤为重要。例如下面，来自github的文档 

Link: <https://api.github.com/user/repos?page=3&per_page=100>; rel="next", 
<https://api.github.com/user/repos?page=50&per_page=100>; rel="last"


自动加载相关的资源

很多时候，自动加载相关资源非常有用，可以很大的提高效率。但是这却和RESTful的原则相背。为了如此，我们可以在url中添加参数：embed（或者expend）。embed可以是一个逗号分隔的串，例如： 

GET /ticket/12embed=customer.name,assigned_user

对应的API返回值如下： 
{
  "id" : 12,
  "subject" : "I have a question!",
  "summary" : "Hi, ....",
  "customer" : {
    "name" : "Bob"
  },
  assigned_user: {
   "id" : 42,
   "name" : "Jim",
  }
}


值得提醒的是，这个功能有时候会很复杂，并且可能导致N+1 SELECT 问题。

重写HTTP方法

有的客户端只能发出简单的GET 和POST请求。为了照顾他们，我们可以重写HTTP请求。这里没有什么标准，但是一个普遍的方式是接受X-HTTP-Method-Override请求头。

速度限制

为了避免请求泛滥，给API设置速度限制很重要。为此 RFC 6585 引入了HTTP状态码429（too many requests）。加入速度设置之后，应该提示用户，至于如何提示标准上没有说明，不过流行的方法是使用HTTP的返回头。

下面是几个必须的返回头（依照twitter的命名规则）：

  • X-Rate-Limit-Limit :当前时间段允许的并发请求数
  • X-Rate-Limit-Remaining:当前时间段保留的请求数。
  • X-Rate-Limit-Reset:当前时间段剩余秒数
为什么使用当前时间段剩余秒数而不是时间戳？

时间戳保存的信息很多，但是也包含了很多不必要的信息，用户只需要知道还剩几秒就可以再发请求了这样也避免了clock skew问题。

有些API使用UNIX格式时间戳，我建议不要那么干。为什么？HTTP 已经规定了使用 RFC 1123 时间格式

鉴权 Authentication

restful API是无状态的也就是说用户请求的鉴权和cookie以及session无关，每一次请求都应该包含鉴权证明。

通过使用ssl我们可以不用每次都提供用户名和密码：我们可以给用户返回一个随机产生的token。这样可以极大的方便使用浏览器访问API的用户。这种方法适用于用户可以首先通过一次用户名-密码的验证并得到token，并且可以拷贝返回的token到以后的请求中。如果不方便，可以使用OAuth 2来进行token的安全传输。

支持jsonp的API需要额外的鉴权方法，因为jsonp请求无法发送普通的credential。这种情况下可以在查询url中添加参数：access_token。注意使用url参数的问题是：目前大部分的网络服务器都会讲query参数保存到服务器日志中，这可能会成为大的安全风险。

注意上面说到的只是三种传输token的方法，实际传输的token可能是一样的。

缓存

HTTP提供了自带的缓存框架。你需要做的是在返回的时候加入一些返回头信息，在接受输入的时候加入输入验证。基本两种方法：

  • ETag：当生成请求的时候，在HTTP头里面加入ETag，其中包含请求的校验和和哈希值，这个值和在输入变化的时候也应该变化。如果输入的HTTP请求包含IF-NONE-MATCH头以及一个ETag值，那么API应该返回304 not modified状态码，而不是常规的输出结果。
  • Last-Modified：和etag一样，只是多了一个时间戳。返回头里的Last-Modified：包含了 RFC 1123 时间戳，它和IF-MODIFIED-SINCE一致。HTTP规范里面有三种date格式，服务器应该都能处理。
出错处理

就像html错误页面能够显示错误信息一样，API 也应该能返回可读的错误信息–它应该和一般的资源格式一致。API应该始终返回相应的状态码，以反映服务器或者请求的状态。API的错误码可以分为两部分，400系列和500系列，400系列表明客户端错误：如错误的请求格式等。500系列表示服务器错误。API应该至少将所有的400系列的错误以json形式返回。如果可能500系列的错误也应该如此。json格式的错误应该包含以下信息：一个有用的错误信息，一个唯一的错误码，以及任何可能的详细错误描述。如下： 

{
  "code" : 1234,
  "message" : "Something bad happened <img src="http://blog.jobbole.com/wp-includes/images/smilies/icon_sad.gif" alt=":-(" class="wp-smiley"> ",
  "description" : "More details about the error here"
}


对PUT,POST,PATCH的输入的校验也应该返回相应的错误信息，例如： 

{
  "code" : 1024,
  "message" : "Validation Failed",
  "errors" : [
    {
      "code" : 5432,
      "field" : "first_name",
      "message" : "First name cannot have fancy characters"
    },
    {
       "code" : 5622,
       "field" : "password",
       "message" : "Password cannot be blank"
    }
  ]
}


HTTP 状态码 

 200 ok  - 成功返回状态，对应，GET,PUT,PATCH,DELETE.
 201 created  - 成功创建。
 304 not modified   - HTTP缓存有效。
 400 bad request   - 请求格式错误。
 401 unauthorized   - 未授权。
 403 forbidden   - 鉴权成功，但是该用户没有权限。
 404 not found - 请求的资源不存在
 405 method not allowed - 该http方法不被允许。
 410 gone - 这个url对应的资源现在不可用。
 415 unsupported media type - 请求类型错误。
 422 unprocessable entity - 校验错误时用。
 429 too many request - 请求过多。


原文链接：Vinay Sahni，编译：感谢@bruce-accumulate 的热心翻译
译文链接：http://blog.jobbole.com/41233/
来自: 伯乐在线
14
顶
0
踩
评论 共 5 条 请登录后发表评论
5 楼 jive 2013-09-06 09:30
http://www.oschina.net/translate/best-practices-for-a-pragmatic-restful-api
4 楼 youjianbo_han_87 2013-06-23 11:41
最佳实践？
3 楼 asialee 2013-06-18 14:10
挺好的，平时都没怎么注意过。
2 楼 lihao312 2013-06-14 13:12 
不过restful蛮好的
1 楼 jinnianshilongnian 2013-06-14 08:33
几个问题：
1、图片挂了
2、GET /ticketssort=-priority  等地址都是错误的应该加"?" 如
GET /tickets?sort=-priority
3、原文地址错误，应该是
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • Restful API 设计最佳实践

    Restful API成熟度在Richardson Maturity Model模型中，将RESTful分为4个等级：4个等级分别是：第一级（Level 0）的 Web 服务仅使用 HTT...

  • RESTful API 设计最佳实践1

    Roy Felding 在他论文 network based software architectures 的 第五章 中首次介绍了这些原则。这些REST的关键

  • RESTful图书管理系统架构设计-restful api 设计最佳实践WORD范本.docx

    RESTful图书管理系统架构设计-restful api 设计最佳实践WORD范本.docx

  • RESTful API设计最佳实践（转译）

    RESTful API设计最佳实践（转译）每个资源，使用两个URL用名词替代动词表示URL使用HTTP方法来操作URL在表示集合URL上，使用POST来创建新的资源在表示特定袁术URL上，使用PUT来表示更新资源坚持使用复数名词使用“？...

  • Restful api 设计最佳实践

    ● CURD的操作 ○ GET /users # 获取user列表 ○ GET /users/12 # 查看某个具体的user ○ POST /users # 新建一个user ○ PUT /users/12 # 更新user 12 ○ DELETE /users/12 #删除user 12 ...

  • Restful API设计最佳实践

    1. Restful REST(Representational State Transfer)，表现层状态转移。它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 表现层是资源的表现层，对于网络中的资源就需要URI...

  • RESTful API 设计指南，RESTful API 设计最佳实践

    RESTful API 设计指南，RESTful API 设计最佳实践 网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备......）。 因此，必须有一种统一的机制，...

  • 洛谷愚人节比赛.pdf

    洛谷愚人节比赛.pdf

  • ### 文章总结：北京迅为 iTOP-3568 开发板 Linux 系统开发和应用开发手册. **文档概述

    内容概要：本文档是北京迅为电子有限公司针对iTOP-3568开发板的Linux系统开发和应用开发手册，详细介绍了开发板在Linux系统下的配置与开发方法。手册涵盖Buildroot、Debian、Ubuntu等多个Linux发行版的系统开发笔记，涉及屏幕设置、待机和锁屏、显示颜色格式、分辨率和缩放、静态IP设置、Qt程序操作、开机自启、音频视频和摄像头开发、VNC和ToDesk远程控制软件安装等内容。同时，手册还提供了关于Buildroot编译常见问题的解决方案、U-Boot和内核开发细节，以及IO电源域的配置方法。手册不仅适用于初次接触嵌入式Linux系统的开发者，也适合有一定经验的研发人员深入学习。 适合人群：具备一定编程基础，尤其是对Linux系统和嵌入式开发有一定了解的研发人员，工作1-3年的工程师，以及希望深入了解嵌入式Linux系统开发的爱好者。 使用场景及目标：①帮助用户掌握iTOP-3568开发板在Linux系统下的基本配置与高级开发技巧；②指导用户解决Linux系统开发中遇到的常见问题；③为用户提供详细的编译和调试指南，确保开发板能

  • 基于MATLAB2020b的CNN-LSTM与GTO算法优化的电力负荷预测研究

    内容概要：本文探讨了基于MATLAB2020b平台，采用CNN-LSTM模型结合人工大猩猩部队(GTO)算法进行电力负荷预测的方法。首先介绍了CNN-LSTM模型的基本结构及其在处理多变量输入（如历史负荷和气象数据）方面的优势。随后详细解释了模型各层的功能，包括卷积层、池化层、LSTM层和全连接层的作用。接着讨论了超参数选择的重要性，并引入GTO算法来进行超参数优化，提高模型预测精度。文中展示了具体的MATLAB代码示例，涵盖了数据预处理、模型构建、训练配置等方面的内容。此外，还分享了一些实践经验，如卷积核配置、LSTM节点数设定等。 适合人群：从事电力系统数据分析的研究人员和技术人员，尤其是对深度学习应用于电力负荷预测感兴趣的读者。 使用场景及目标：适用于需要精确预测未来电力负荷的场合，旨在帮助电力公司更好地规划发电计划，优化资源配置，保障电网安全稳定运行。通过本篇文章的学习，读者可以掌握如何使用MATLAB实现CNN-LSTM模型，并学会运用GTO算法优化超参数，从而提升预测准确性。 其他说明：文章强调了数据质量和预处理步骤的重要性，指出高质量的输入数据能够显著改善预测效果。同时提醒读者注意模型训练过程中的一些常见陷阱，如避免过度拟合等问题。

  • TIG焊接工艺中二维电弧仿真的理论与程序实现

    内容概要：本文详细介绍了TIG（钨极惰性气体保护焊）二维电弧仿真的理论基础和程序实现。首先阐述了TIG电弧的本质及其在二维仿真中的数学描述，主要采用磁流体动力学（MHD）方程进行建模。接着展示了如何使用Python生成仿真所需的网格，并初始化温度场、速度场和电场强度等物理参数。随后，通过迭代求解MHD方程，逐步更新各物理量，最终得到电弧内部的温度、速度和电场分布情况。通过对仿真结果的分析，能够深入了解焊接过程中熔化和凝固的现象，从而优化焊接参数，提高焊接质量。 适合人群：从事焊接工程、材料科学及相关领域的研究人员和技术人员，尤其是对TIG焊接工艺感兴趣的学者。 使用场景及目标：适用于希望深入了解TIG焊接过程并希望通过仿真手段优化焊接参数的研究人员。目标是通过仿真更好地理解电弧行为，进而改善焊接质量和效率。 其他说明：文中还提到了一些实用技巧，如网格划分、边界条件设置、求解器选择等方面的注意事项，以及如何使用不同软件工具（如MATLAB、ParaView）进行数据可视化。此外，强调了多语言混合编程的优势，并提供了一些常见的调试和优化建议。

  • jenkins操作诶udrtyui897t86r5drctvghuiyft

    jenkins操作诶udrtyui897t86r5drctvghuiyft

  • 帆软本地打印插件FinePrint 8.0版本

    帆软本地打印插件FinePrint 8.0版本，适用于FineReport8

  • 基于TMS320F2812的光伏并网逆变器设计与MATLAB仿真及DSP代码实现

    内容概要：本文详细介绍了基于TMS320F2812 DSP芯片的光伏并网逆变器设计方案，涵盖了主电路架构、控制算法、锁相环实现、环流抑制等多个关键技术点。首先，文中阐述了双级式结构的主电路设计，前级Boost升压将光伏板输出电压提升至约600V，后级采用三电平NPC拓扑的IGBT桥进行逆变。接着，深入探讨了核心控制算法，如电流PI调节器、锁相环(SOFGI)、环流抑制等，并提供了详细的MATLAB仿真模型和DSP代码实现。此外，还特别强调了PWM死区时间配置、ADC采样时序等问题的实际解决方案。最终，通过实验验证，该方案实现了THD小于3%，MPPT效率达98.7%，并有效降低了并联环流。 适合人群：从事光伏并网逆变器开发的电力电子工程师和技术研究人员。 使用场景及目标：适用于光伏并网逆变器的研发阶段，帮助工程师理解和实现高效稳定的逆变器控制系统，提高系统的性能指标，减少开发过程中常见的错误。 其他说明：文中提供的MATLAB仿真模型和DSP代码可以作为实际项目开发的重要参考资料，有助于缩短开发周期，提高成功率。

  • 基于鲸鱼优化算法与深度极限学习机的回归预测模型(WOA-DELM)及其应用

    内容概要：本文详细介绍了如何结合鲸鱼优化算法（WOA）和深度极限学习机（DELM）构建回归预测模型。首先，文章解释了鲸鱼优化算法的基本原理，这是一种受座头鲸群体狩猎行为启发的元启发式优化算法。接着，阐述了深度极限学习机的工作机制，它结合了极限学习机的快速学习能力和深度学习的层次结构。随后，文章展示了如何使用时间窗法处理数据，并构建自动编码器和极限学习机的具体步骤。特别地，文中详细描述了如何利用鲸鱼优化算法优化自动编码器的输入权重与偏置，从而提高模型的预测性能。最后，给出了完整的代码实现，包括数据预处理、模型构建、优化和预测等环节。 适合人群：具备一定机器学习基础的研究人员和技术开发者，尤其是对时间序列预测感兴趣的从业者。 使用场景及目标：适用于需要高精度回归预测的任务，如金融数据分析、能源消耗预测等领域。主要目标是通过优化模型参数，提高预测的准确性。 其他说明：本文提供的代码示例详尽且易于修改，用户只需替换自己的数据路径即可复现实验结果。同时，文中还提供了调参的小技巧，有助于进一步提升模型表现。

  • ### 标题：【电动船舶充电通信协议】基于CAN的非船载传导式充电机与电动船舶间数字通信协议设计及应用

    内容概要：T/CIN 029—2024标准规定了非船载传导式充电机与电动船舶之间的数字通信协议，涵盖了一般要求、通信物理层、数据链路层、应用层、充电总体流程、报文分类、格式和内容等方面。该标准旨在确保电动船舶连接到直流电网时，充电机与电池管理系统（BMS）或船舶管理系统（SMS）之间的稳定通信。标准详细定义了各层的通信要求，如物理层的ISO 11898-1和SAE J1939-11规范，数据链路层的CAN扩展帧格式，以及应用层的参数组编号和传输协议。此外，还详细描述了充电的六个阶段（物理连接、低压辅助上电、充电握手、参数配置、充电和结束）的具体流程和涉及的报文格式，确保了充电过程的安全性和可靠性。 适用人群：从事电动船舶充电系统设计、开发、维护的技术人员及工程师；相关行业的研究人员；对电动船舶充电通信协议感兴趣的学者和专业人士。 使用场景及目标：① 为电动船舶充电系统的开发和优化提供技术依据；② 确保充电机与BMS/SMS之间的高效、可靠通信；③ 保障充电过程的安全性和稳定性，防止因通信故障导致的充电中断或事故。 其他说明：本标准由中国航海学会发布，适用于电动船舶连接到直流电网时的充电通信，为电动船舶行业的标准化发展提供了重要支持。标准中还包含了详细的故障诊断代码和报文格式，帮助技术人员快速定位和解决问题。

  • vue 基础语法使用心得

    vue 基础语法使用心得

  • 根据“意见”创新银发经济新模式.pptx

    根据“意见”创新银发经济新模式.pptx

Global site tag (gtag.js) - Google Analytics