方法和接受头


Zato3.1包含了新的方法来管理对REST服务的访问,基于HTTP请求中的输入方法和接受头——下面是它们在实践中的使用方法。

背景

在Zato 3.1之前,您总是可以通过在服务中实现handle _动词方法来构建一个对单个HTTP动词做出反应的REST API,例如:

class MyService(Service):

    def handle_GET(self):
        # Reacts to GET requests
        pass

    def handle_POST(self):
        # Reacts to POST requests
        pass

    # Any other handle_VERB method will be used accordingly



这是可行的,并将继续在所有未来的Zato版本中按预期工作。

但是,如果使用SimpleIO,并且将所有的处理程序方法都保存在同一个服务中,那么它们都共享同一个SIO定义;这并不总是令人满意的——例如,开机自检的输入可能与删除接收的输入无关。

休息频道网址路径

在Zato 3.1中,可以创建REST通道,这些通道具有相同的URL路径,但每个通道上安装了不同的服务。这可以针对所需的每个HTTP动词单独进行。

以前它是一个带有多个handle _动词方法的单一服务。现在,它可以是一组服务,每个服务对一个不同的HTTP动词做出反应,所有服务都安装在同一个网址路径上。

在某种程度上,这是以前支持的,但是,如果不使用handle _ VERB方法,则URL路径必须是不同的,例如

GET /api/user
DELETE /api/user/delete
POST /api/user/create


在3.1+中,这可以简化为:

GET /api/user
DELETE /api/user
POST /api/user


现在,动词+路径的每个组合对于一个REST通道可能是唯一的,而以前每个通道需要有自己的URL路径。

而且,因为每个通道可能有自己单独的服务,这也意味着每个服务可能有自己的SimpleIO定义;然后,服务变得不那么依赖于REST。

接受标题

这在3.1中是一个全新的特性,它允许你有不同的休息通道,这取决于请求的接受头。

例如,假设我们希望在POST /api/invoice下处理传入的发票,但是我们希望有两个服务对同一个端点做出反应,一个用于JSON,现在用于PDF发票。

这可以通过在其通道中配置“接受”标头来实现,如下所示—请注意,在这两种情况下,方法和网址路径都是相同的,但“接受”和服务是不同的,因为每个服务对“接受”的值不同:

Process JSON invoice

处理JSON发票

Process PDF invoice

处理PDF发票


接受头模式

我们可以做得更好,利用接受标题模式——星号表示任何字符。这将配置通道来处理匹配符合模式的任何值的请求。(例如,text/*将表示text/csv、text/xml或任何以text/开头的内容。(

Processing requesting matching the given pattern

处理请求,匹配给定的模式


然而,由于它可以是许多输入MIME类型,此时我们可能需要知道实际值是什么——这可以通过self.wsgi_environ从WSGI环境中提取。

摘要

Zato 3.1对如何构建REST通道进行了改进和向后兼容的更改。

它现在将支持更多的用例,例如具有不同的超文本传输协议动词和独立的简单定义的单一网址路径通道,或者每个通道不同的超文本传输协议接受头。

反过来,这让我们可以构建REST APIs,这些API在设计上更加灵活和有弹性,以应对不同的输入标准。