附：REST服务基本介绍

已于 2023-03-19 19:51:12 修改
阅读量242 收藏
点赞数 1
分类专栏： IRIS REST服务 文章标签： restful 开发语言
于 2023-03-04 21:08:37 首次发布
原文链接：https://blog.csdn.net/u_hcy2000/article/details/122216769?spm=1001.2014.3001.5506
版权

1 资源识别

REST服务中的API将不再以执行了什么动作为中心，而是以资源为中心。一些对资源的通用操作有添加，取得，修改，删除，以及对符合特定条件的资源进行列表操作。

1.1 识别方法

  1. （关注动作后的宾语）我们对某个操作不要再关注它所执行的动作，而是关心它所操作的宾语。通常情况下，该宾语就会是REST系统中的资源。

  2. 动作可能并不存在着它所操作的宾语，变化的实体实际上就是一种资源。

  3. 在抽象资源的过程中，我们需要按照自顶向下的方式，即首先辨识出系统中的最主要资源，然后再辨识这些主要资源的子资源

  4. 如果一个资源是主资源，那么其可以被不同的资源实例包含引用而不会产生歧义。而如果一个资源是子资源，那么被不同的资源实例引用可能会产生歧义。

1.2 判断REST服务所定义的资源是否合理

  1. 考虑对该资源的CRUD是否有意义，从而验证资源的定义是否合理。
  2. 检查资源是否需要除CRUD之外的动词来操作。该方法用来检查资源中是否还有子资源没有被抽象。
  3. 资源是否是被整体使用，创建和删除。该方法用来探测是否一个子资源应该是一个主资源。如果在删除一个资源的时候，其子资源还可以被其它资源重用，那么该子资源实际上具有较高的重用性，应该是一个主资源。

2 资源的URL设计

在HTTP中，一个URL主要由以下几个部分组成：

  • 协议。即HTTP以及HTTPS。

  • 主机名和端口。如www.egoods.com:8421

  • 资源的相对路径。如/api/categories。

  • 请求参数。即由问号开始的由键值对组成的字符串：?page=1&page_size=20

在为一个资源设计其所对应的URL时，我们需要着重考虑第三部分和第四部分组成。

  1. API必须有版本的概念
  2. url中大小写不敏感，不要出现⼤写字⺟
  3. 使-不是使_做url路径中的字符串连接
  4. 有一份文档

2.1 方法步骤

  1. 明确所有的资源都应该置于举个例子如/api这样一个相对路径下之后，为资源定义对应的URL

  2. 例如egoods网站中的产品分类就是一个主资源，我们会为其分配如下URL：/api/categories

    注：每类主资源都将拥有一个特定于该类资源的URL。这些URL就对应着相应资源实例的集合

  3. 某个主资源类型中的特定实例，那么我们就需要在该类主资源所对应的URL之后添加该实例的ID。如egoods网站中的食品分类的ID为1：/api/categories/1

  4. 一个资源实例中还可能拥有子资源，包含一个子资源的集合：/api/items/23456/shipments

    仅仅包含一个子资源集合中的一个子资源： /api/items/23456/shipments/87256

    仅仅包含一个子资源且子资源只有一个： /api/items/23456/discount

2.2 资源在URL中是单数还是复数

如果一个URL所对应的资源是使用复数表示的，那么该类型的资源可能有多个。对该URL发送Get请求可能返回该资源的一个列表。

反之，如果一个URL所对应的资源是使用单数表示的，那么该类型的资源将只有一个，因此对该URL发送Get请求将只返回该资源的一个实例。

2.3 使用合适的动词

  1. GET 查询

  2. POST 新增

  3. PUT 更新

  4. DELETE 删除

  5. patch 更新部分资源

CRUD：

在一个资源的生命周期之内常常会发生一系列通用事件（CRUD）。

一开始，一个资源并不存在。只有用户或REST服务创建了该资源以后其才存在，也即是上面所列出的通用事件中的C，Create。

在一个资源创建完毕以后，用户可能会从服务端请求该资源的表示，也就是上面所列出的通用事件的R，Retrieve。

在特定情况下，用户可能决定要更新该资源，因此会使用上面的通用事件中的U，即Update来更新资源。

而在资源不再需要的时候，用户可能需要通过通用事件D，即Delete来删除该资源。同时用户有时也需要列出属于特定类型资源的资源实例，即通过List操作来得到属于特定类型的资源的列表。

POST动词会在目标URI之下创建一个新的子资源。例如在向服务端发送下面的请求时，REST系统将创建一个新的分类

POST /api/categories
Host: www.egoods.com
Authorization: Basic xxxxxxxxxxxxxxxxxxx
Accept: application/json

{
   "label" : "Electronics",
   ……
}

PUT则是根据请求创建或修改特定位置的资源。此时向服务端发送的请求的目标URI需要包含所处理资源的ID：

POST /api/categories/8fa866a1-735a-4a56-b69c-d7e79896015e
Host: www.egoods.com
Authorization: Basic xxxxxxxxxxxxxxxxxxx
Accept: application/json

{
   "label" : "Electronics",
   ……
}

怎么区分是用post还是put？
首先就是资源的ID是如何生成的。如果希望客户端在创建资源的时候显式地指定该资源的ID，那么就需要使用PUT。而在由服务端为该资源自动赋予ID的时候，我们就需要在创建资源时使用POST。
在决定使用PUT创建资源的时候，防止资源URI与其它资源所具有的URI重复的任务需要由客户端来保证。在这种情况下，客户端常常使用GUID/UUID作为将资源的ID。但是到底使用GUID/UUID还是由服务端来生成ID不仅仅和REST有关，更会对数据库性能等多个方面产生影响。因此在决定使用它们之前要仔细地考虑清楚。

同时需要注意的是，因为REST要求客户只可以通过服务端返回结果中所包含的信息来得到下一步操作所需要的信息，因此客户端仅仅可以决定资源的ID，而URI中的其它部分则需要从之前得到的响应中取得。

使用put还是post需要考虑的问题？

  1. PUT的等幂性是否对REST系统的设计有所帮助？由于在同一个URI上调用两次PUT所得到的结果相同。因此用户在没有接到PUT请求响应时可以放心地重复发送该响应。这在网络丢包较为严重时是一个非常好的功能。反过来，在同一个URI上调用两次POST将可能创建两个独立的子资源。

  2. 否将资源的创建和更新归结为一个API可以简化用户对REST服务的使用？用户可以通过PUT动词来同时完成创建和更新一个资源这两种不同的任务。这样的好处在于简化了REST服务所提供的接口，但是反过来也让一个API执行了两种不同的任务，在一定程度上违反了API设计时每个API都需要有明确的意义这一原则。

除此之外，另外一对类似的动词则是PUT和PATCH。两者之间的不同则在于PUT是对整个资源的更新，而PATCH则是对部分资源的更新。而该动词的局限性则在于对该动词的支持程度。毕竟在某些类库中并没有提供原生的对PATCH动词的支持。

2.4 使用标准的状态码

到底如何组织这些响应代码需要用户根据所编写的项目决定，尤其是该产品的使用者来决定。在定义一个平台时，尽量使用更多的HTTP响应代码，因为用户极有可能通过该平台编写自己的第三方软件。而在为一个普通的产品定义REST API时，将响应代码定得非常专业可能反而导致易用性的下降。

IANA提供了一张各个状态码所对应的RFC协议的列表，从而可以很容易地找到各个状态码所对应的RFC协议以及其所在的章节。该列表的地址为：http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

2.5 选择适当的表示结构

在一个基于HTTP的REST服务中，我们可以使用JSON，也可以使用XML，甚至是自定义的MIME类型来表示资源。这些表现形式常常是等效的。
客户端和服务端对所使用负载类型的协商通常都按照协议所规定的标准协商过程来完成。例如对于一个基于HTTP的REST服务，我们就需要使用Accept头来标示客户端所可以接受的负载类型。

GET /api/categories
Host: www.egoods.com
Authorization: Basic xxxxxxxxxxxxxxxxxxx
Accept: application/json

而在服务端支持的情况下，返回的响应就将使用该MIME类型组织其负载：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: xxx

2.6 负载的自描述性

REST系统中所传递的各个消息的负载需要提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作，并可以根据负载中所包含的对其它各资源的引用来访问各个资源。这也对负载的自描述性提出了更高的要求。
如何自定义资源的json

在一个基于HTTP的REST系统中，我们常常在资源的引用中包含一定量的描述信息。这主要因为两点：
提高性能。在一个对资源的引用中添加了用于显示的属性后，客户端页面可以避免再次通过url发送请求得到资源的具体描述，以得到用于显示的信息。
自描述性的要求。如果一个资源中包含了一个对其它资源进行引用的数组，那么用户就需要通过该标签来决定到底访问哪个被引用的资源。
有时候，一个资源可能并不支持特定用户执行某个操作。例如一个管理员所创建的资源可能对普通用户只读。在这种情况下，我们需要禁止普通用户对该资源的修改和删除。为了能明确地告知用户他所具有的权限，我们需要一个能显式地标示用户可以在一个资源上所执行操作的组成。在REST响应中，这种组成被称为Hypermedia Controls。例如对于一个普通用户，其从egoods中所返回的分类列表将如下所示：
我们通过actions域显式地标示了用户可以在各个类别上所能执行的操作。

1 HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: xxx
 
[
   {
      "label" : "Food",
      "uri" : "/api/categories/1",
      "actions" : ["GET", "PUT", "DELETE"]
   }, {
      "label" : "Clothes",
      "uri" : "/api/categories/2",
      "actions" : ["GET", "PUT", "DELETE"]
   }
   ...
   {
      "label" : "Electronics",
      "uri" : "/api/categories/25",
      "actions" : ["GET", "PUT", "DELETE"]
   }
]

2.7 版本管理

如果一个资源由不同的URI标示其不同的表现形式，那么用户将无法通过一个响应中所标示的URI得到其它URI所指向的表示形式。而且在URI中添加了有关版本的信息也就标示着其可能会随着时间的推移发生变化。

方法一：
一种使用独立URI的方法是基于Accept头。
在一个请求中，我们常常标明了Accept头，以标示客户端希望得到的表现形式。在该头中，用户可以添加所请求的资源的版本信息：

GET /api/categories/1
Host: www.egoods.com
Authorization: Basic xxxxxxxxxxxxxxxxxxx
Accept: application/vnd.ambergarden.egoods-v3+json

而在接收到该请求之后，服务端将返回该资源的第三个版本

HTTP/1.1 200 OK
Content-Type: application/vnd.ambergarden.egoods-v3+json
Content-Length: xxx

{
   "uri" : "/api/categories/1",
   "label" : "Food",
  ……
}

方法二：
⼀种基于重定向的解决⽅案也被提出。该⽅案允许⼀个REST系统提供多个版本的API，并在URI中标明版本号：

/api/v2/categories
/api/v1/categories

这样⽤⼾可以选择使⽤特定版本的REST API来实现客⼾端功能。由于其使⽤固定版本的API，因此并不存在着⼀个资源有多种表⽰，进⽽违反了HATEOAS约束的问题。

3 详细RESTful API接口设计参考

3.1 URL 设计

3.1.1 动词 + 宾语

RESTful 的核心思想就是，客户端发出的数据操作指令都是"动词 + 宾语"的结构。比如，GET /articles这个命令，GET是动词，/articles是宾语。

动词通常就是五种 HTTP 方法，对应 CRUD 操作。

  • GET：读取（Read）
  • POST：新建（Create）
  • PUT：更新（Update）
  • PATCH：更新（Update），通常是部分更新
  • DELETE：删除（Delete）

根据 HTTP 规范，动词一律大写。

3.1.2 动词的覆盖

有些客户端只能使用GET和POST这两种方法。服务器必须接受POST模拟其他三个方法（PUT、PATCH、DELETE）。

这时，客户端发出的 HTTP 请求，要加上X-HTTP-Method-Override属性，告诉服务器应该使用哪一个动词，覆盖POST方法。

POST /api/Person/4 HTTP/1.1  
X-HTTP-Method-Override: PUT

上面代码中，X-HTTP-Method-Override指定本次请求的方法是PUT，而不是POST。

3.1.3 宾语必须是名词

宾语就是 API 的 URL，是 HTTP 动词作用的对象。它应该是名词，不能是动词。比如，/articles这个 URL 就是正确的，而下面的 URL 不是名词，所以都是错误的。

  • /getAllCars
  • /createNewCar
  • /deleteAllRedCars

3.1.4 复数 URL

既然 URL 是名词，那么应该使用复数，还是单数？

这没有统一的规定，但是常见的操作是读取一个集合，比如GET /articles（读取所有文章），这里明显应该是复数。

为了统一起见，建议都使用复数 URL，比如GET /articles/2要好于GET /article/2。

3.1.5 避免多级 URL

常见的情况是，资源需要多级分类，因此很容易写出多级的 URL，比如获取某个作者的某一类文章。

GET /authors/12/categories/2

这种 URL 不利于扩展，语义也不明确，往往要想一会，才能明白含义。

更好的做法是，除了第一级，其他级别都用查询字符串表达。

GET /authors/12?categories=2

下面是另一个例子，查询已发布的文章。你可能会设计成下面的 URL。

GET /articles/published

查询字符串的写法明显更好。

GET /articles?published=true

3.2 状态码

3.2.1 状态码必须精确

客户端的每一次请求，服务器都必须给出回应。回应包括 HTTP 状态码和数据两部分。

HTTP 状态码就是一个三位数，分成五个类别。

  • 1xx：相关信息
  • 2xx：操作成功
  • 3xx：重定向
  • 4xx：客户端错误
  • 5xx：服务器错误

这五大类总共包含100多种状态码，覆盖了绝大部分可能遇到的情况。每一种状态码都有标准的（或者约定的）解释，客户端只需查看状态码，就可以判断出发生了什么情况，所以服务器应该返回尽可能精确的状态码。

API 不需要1xx状态码，下面介绍其他四类状态码的精确含义。

3.2.2 2xx 状态码

200状态码表示操作成功，但是不同的方法可以返回更精确的状态码。

  • GET: 200 OK
  • POST: 201 Created
  • PUT: 200 OK
  • PATCH: 200 OK
  • DELETE: 204 No Content

上面代码中，POST返回201状态码，表示生成了新的资源；DELETE返回204状态码，表示资源已经不存在。

此外，202 Accepted状态码表示服务器已经收到请求，但还未进行处理，会在未来再处理，通常用于异步操作。下面是一个例子。

HTTP/1.1 202 Accepted

{
  "task": {
    "href": "/api/company/job-management/jobs/2130040",
    "id": "2130040"
  }
}

3.2.3 3xx 状态码

API 用不到301状态码（永久重定向）和302状态码（暂时重定向，307也是这个含义），因为它们可以由应用级别返回，浏览器会直接跳转，API 级别可以不考虑这两种情况。

API 用到的3xx状态码，主要是303 See Other，表示参考另一个 URL。它与302和307的含义一样，也是"暂时重定向"，区别在于302和307用于GET请求，而303用于POST、PUT和DELETE请求。收到303以后，浏览器不会自动跳转，而会让用户自己决定下一步怎么办。下面是一个例子。

HTTP/1.1 303 See Other
Location: /api/orders/12345

3.2.4 4xx 状态码

4xx状态码表示客户端错误，主要有下面几种。

400 Bad Request：服务器不理解客户端的请求，未做任何处理。

401 Unauthorized：用户未提供身份验证凭据，或者没有通过身份验证。

403 Forbidden：用户通过了身份验证，但是不具有访问资源所需的权限。

404 Not Found：所请求的资源不存在，或不可用。

405 Method Not Allowed：用户已经通过身份验证，但是所用的 HTTP 方法不在他的权限之内。

410 Gone：所请求的资源已从这个地址转移，不再可用。

415 Unsupported Media Type：客户端要求的返回格式不支持。比如，API 只能返回 JSON 格式，但是客户端要求返回 XML 格式。

422 Unprocessable Entity ：客户端上传的附件无法处理，导致请求失败。

429 Too Many Requests：客户端的请求次数超过限额。

3.2.5 5xx 状态码

5xx状态码表示服务端错误。一般来说，API 不会向用户透露服务器的详细信息，所以只要两个状态码就够了。

500 Internal Server Error：客户端请求有效，服务器处理时发生了意外。

503 Service Unavailable：服务器无法处理请求，一般用于网站维护状态。

3.3 服务器回应

3.3.1 不要返回纯本文

API 返回的数据格式，不应该是纯文本，而应该是一个 JSON 对象，因为这样才能返回标准的结构化数据。所以，服务器回应的 HTTP 头的Content-Type属性要设为application/json。

客户端请求时，也要明确告诉服务器，可以接受 JSON 格式，即请求的 HTTP 头的ACCEPT属性也要设成application/json。下面是一个例子。

GET /orders/2 HTTP/1.1 
Accept: application/json

3.3.2 发生错误时，不要返回 200 状态码

有一种不恰当的做法是，即使发生错误，也返回200状态码，把错误信息放在数据体里面，就像下面这样。

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "failure",
  "data": {
    "error": "Expected at least two items in list."
  }
}

上面代码中，解析数据体以后，才能得知操作失败。

这张做法实际上取消了状态码，这是完全不可取的。正确的做法是，状态码反映发生的错误，具体的错误信息放在数据体里面返回。下面是一个例子。

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Invalid payoad.",
  "detail": {
     "surname": "This field is required."
  }
}

3.3.3 提供链接

API 的使用者未必知道，URL 是怎么设计的。一个解决方法就是，在回应中，给出相关链接，便于下一步操作。这样的话，用户只要记住一个 URL，就可以发现其他的 URL。这种方法叫做 HATEOAS。

举例来说，GitHub 的 API 都在 api.github.com 这个域名。访问它，就可以得到其他 URL。

{
  ...
  "feeds_url": "https://api.github.com/feeds",
  "followers_url": "https://api.github.com/user/followers",
  "following_url": "https://api.github.com/user/following{/target}",
  "gists_url": "https://api.github.com/gists{/gist_id}",
  "hub_url": "https://api.github.com/hub",
  ...
}

上面的回应中，挑一个 URL 访问，又可以得到别的 URL。对于用户来说，不需要记住 URL 设计，只要从 api.github.com 一步步查找就可以了。

HATEOAS 的格式没有统一规定，上面例子中，GitHub 将它们与其他属性放在一起。更好的做法应该是，将相关链接与其他属性分开。

HTTP/1.1 200 OK
Content-Type: application/json

{
  "status": "In progress",
   "links": {[
    { "rel":"cancel", "method": "delete", "href":"/api/status/12345" } ,
    { "rel":"edit", "method": "put", "href":"/api/status/12345" }
  ]}
}
wanyh2023
关注
  • 1
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
什么叫REST服务
呼卓宇的博客
03-25 2万+
rest服务是一种Web服务架构，其目标是为了创建具有良好扩展性的分布式系统。 rest应该具备以下条件： 使用客户/服务器模型(简称C/S结构，是一种网络架构，它把客户端 (Client) 与服务器(Server) 区分开来。 每一个客户端软件的实例都可以向一个服务器或应用程序服务器发出请求。) 例如前后端分离，页面和服务不在同一服务器上运行。 层次化的系统 例如一个父系统下有多个子模...
REST服务介绍
文武傲群雄，彳亍定江山
10-09 3429
REST 产生背景 Web服务和WCF它们虽然使用了HTTP协议，但是其实建立在 SOAP 上，以至于我们提到 Web 服务就会想到 SOAP，也就是说，他们并没有直接建立在 HTTP上，仅仅使用HTTP作为一种夹带其他的应用协议穿越防火墙的方法，可以说，他们没有充分挖掘并利用HTTP协议。 在HTTP协议中，消息通过在那些资源的表述上的转移和操作，来对资源执行一些动作，从而反映出Web架构的语义...
异步处理REST服务
whaleluo的博客
02-13 905
异步处理REST服务，提高吞吐量 使用Runnable 异步处理REST服务 先看同步处理 package com.whale.web.async; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.web.bind.annotation.RequestMapping; im...
REST服务简介和实践
u_hcy2000的博客
12-29 2607
1 资源识别 REST服务中的API将不再以执行了什么动作为中心，而是以资源为中心。一些对资源的通用操作有添加，取得，修改，删除，以及对符合特定条件的资源进行列表操作。 1.1 识别方法 （关注动作后的宾语）我们对某个操作不要再关注它所执行的动作，而是关心它所操作的宾语。通常情况下，该宾语就会是REST系统中的资源。 动作可能并不存在着它所操作的宾语，变化的实体实际上就是一种资源。 在抽象资源的过程中，我们需要按照自顶向下的方式，即首先辨识出系统中的最主要资源，然后再辨识这些主要资源的子资源 如果一个资源
REST 服务
最新发布
qq_43806430的博客
11-15 511
例如服务端通过token缓存已登录过的用户信息，客户端请求会带一个token过来，后台服务通过带过来的token在缓存中取出用户信息，提高效率。Server提供的RESTful API中，URL中只使用名词来指定资源，原则上不使用动词。Server和Client之间传递某资源的一个表现形式，比如用JSON，XML传输文本，或者用JPG，WebP传输图片等。例如，一个项目的所有模块都整合到一起，all-in-one，打成一个包，多个服务，整合到一个端口下。用HTTP协议里的动词来实现资源的添加，修改。
h2-embedded:通过REST API和基本前端以编程方式嵌入H2
05-14
H2嵌入式使用SpringBoot和Spring Security通过REST API以编程方式嵌入H2 掌握 开发H2控制台H2 Web控制台在已可用要登录，请使用org.systemexception.h2embedded.SecurityConfig的ADMIN角色凭据。文献资料查看随附的...
Rest API 测试工具（RestclientV3.2.2），内附简单安装说明。
07-14
首先，让我们了解一下REST（Representational State Transfer）的基本概念。REST是一种网络应用程序的设计风格和开发方式，基于HTTP协议，强调资源的表述状态转移。RESTful API则是遵循REST原则设计的Web服务接口，...
数据表示项目：使用基本的Flask服务器创建一个Web应用程序，该服务器具有REST API（用于执行CRUD操作）和一个数据库表，以及一个附带的Web界面，使用AJAX调用来执行这些CRUD操作
02-14
使用基本的Flask服务器创建一个Web应用程序，该服务器在一个数据库表上具有REST API（以执行CRUD操作），并使用AJAX调用随附的Web界面来执行这些CRUD操作。 对于这个项目，我将使用DVD租赁数据库，其中包含两个表...
rest-api-mlbbguide：用于移动图例的非正式REST API：带有Express，Sequelize（MySQL），JWT的Node JS的Bang Bang
02-09
api-mlbbguide”是一个专门针对移动游戏“Bang Bang”的非正式REST API实现，它利用了Node.js的强大功能，结合Express框架、Sequelize ORM以及JSON Web Tokens (JWT)进行身份验证，构建了一个高效、安全的后端服务。...
2022最新去水印小程序，附安装教程
10-10
安装此去水印小程序的过程相对简单，以下是基本步骤： 1. **下载源码**：首先，你需要从提供的压缩包中获取源码，其中包含所有必要的文件和文档。 2. **上传到WordPress**：登录到你的WordPress管理后台，导航到...
三步发布java方式的rest服务
03-20
NULL 博文链接：https://virgoooos.iteye.com/blog/787167
WinCC 集成到MES和ERP的IT解决方案
07-23
WinCC 集成到MES和ERP的IT解决方案,应该说相当有用的材料。
HTTP的REST服务简介和最佳实践
05-16
一说到REST，我想大家的第一反应就是“啊，就是那种前后台通信方式。”但是在要求详细讲述它所提出的各个约束，以及如何开始搭建REST服务时，却很少有人能够清晰地说出它到底是什么，需要遵守什么样的准则。 博文地址：https://blog.csdn.net/adparking/article/details/52278794 此PDF文档，只为方便阅读查看
REST服务
weixin_34376562的博客
11-29 167
2019独角兽企业重金招聘Python工程师标准>>> ...
WINCC7.5开启REST接口步骤（Web service）
weloveut的博客
02-26 9758
WINCC7.5开启REST接口步骤（Web service） 1.安装WINCC7.5 SP2（SP2版本支持Web service实时访问变量标签，读取和写入） 安装推荐选择数据包安装 选择满足启动REST接口的组件 手段勾选好ConnectivityPack安装 默认安装好wincc和ConnectivityPack，需要重启电脑 2.打开WINCC项目管理器，创建test1单用户项目 创建单用户项目 修改项目属性 点击进入项目属性 启用REST服务 注意：启用REST接口，浏览端口证书
(全网首发)C#通过Rest接口访问WinCC(1)
HwLib_的博客
02-26 4118
从WinCC V7.5 SP2开始，SIEMENS为WinCC增加了Rest接口，任何一款支持RESTful API规范的软件都可以通过该接口从WinCC读写数据。 为WinCC配置Rest 配置方法可以参见WinCC帮助，里面介绍的比较详细。但是有一点需要注意，就是证书的选择，参见下图所示。 图1 选择证书 完成了Rest设置后，为WinCC添加若干变量。这里我们添加了PAR1-PAR100等一些内部测试变量。 图2 创建变量 C#应用程序 创建一个WinForm应用程序，目..
SpringBoot构建REST服务
ZhangCurie的博客
07-13 1488
文章目录为什么REST？开始管理雇员信息HTTP平台什么才是REST的？简化链接创建REST API 演化支持 API 变更正确响应构建指向 REST API 的链接总结参考 现在，REST已成为事实上的标准，要构建web服务，使用REST很便于生产和消费，微服务架构也有大量的文献描述如何使用REST，下面就来看看如何创建REST服务。 为什么REST？ 表征状态转移（Representional State Transfer），是 Roy Fielding（ HTTP 规范的主要编写者之一）博士在 200
创建REST服务
jhlyh的博客
08-02 335
创建REST服务
REST Service 开发 - 客户端
pmlpml的专栏
04-22 4078
REST Service 的客户端开发是比较简单的，每种框架都提供了各种访问服务端的实现，如 Apache Httpclient, JAX-RS2 client，Feign Client。本文重点罗列客户端异步服务编排技术，服务端异步技术，这些将使得你的云服务更加健壮、高效。
SOA治理实践：REST与Web服务架构
1. **SOA基础**：介绍SOA的基本概念，包括服务的定义、服务之间的交互、以及为何采用SOA来构建分布式系统。 2. **治理框架**：讨论了实施SOA治理所需的一套结构化方法，包括政策制定、服务生命周期管理、服务质量...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值