小编App*_* S.的帖子

我想知道是否间接可能在事务即将提交之前执行触发器？在此触发器中,我将执行一致性检查并在需要时回滚事务.

例如,我有三个表:

users (id, name)
groups (id, name)
user_in_group (user_id, group_id)

我想创建一个触发器,用于验证用户是否始终是组的一部分.不允许孤儿用户.每次插入用户时,此触发器将验证是否还发生了进入user_in_group的相应插入.如果不是,则事务不会提交.

这不能使用简单的基于行或语句的触发器来完成,因为上述场景需要两个单独的语句.

反过来,当从user_in_group中删除时,可以通过基于行的触发器轻松完成.

在我们的项目中,可以通过REST检索所有书籍的列表:

GET http://server/api/books/

可以检索特定书籍如下:

GET http://server/api/books/:id/

删除特定的书很容易:

DELETE http://server/api/books/:id/

现在,我的问题是:以下调用的结果应该是什么:

DELETE http://server/api/books/

显然,所有书籍都被删除了.但是资源书/是否应该被删除？也就是说,在请求之后:

1. 应该GET/books /返回200 OK和空列表？要么
2. 应该获得GET/books/return 404吗？

根据规格说明具体的URI将会消失,我会选择第二种选择.然而,在我看来,这使得事情变得复杂和不合逻辑.拥有一个空的书籍清单更有意义,而不是没有书籍.

你怎么看？

在REST中,它完全与链接有关.基本上,API用户只需要一个链接,即顶级链接.这通常是http:// server/api /或类似的东西.浏览层次结构时会发现所有其他链接.例如,GET / api /可能会为您提供指向/ api/users /和/ api/images /和/ api/users /的链接,可能会为您提供指向/ api/users/john /的链接,依此类推.

那就是说,我想知道是否有某种标准如何格式化这些链接.毕竟,如果全部是关于链接,爬虫应该能够从顶部开始发现系统中的所有资源？

我做了一些研究.XML媒体类型,找不到任何标注的标准.我们选择/ users / resource.有人写

<users>
    <user name='john' uri='/users/john'/>
    <user name='steve' uri='/users/steve'/>
</users>

其他人写

<users>
    <user name='john' link='/users/john'/>
    <user name='steve' link='/users/steve'/>
</users>

其他人使用xlink,例如:

<users>
    <user name='john' xlink:href='/users/john'/>
    <user name='steve' xlink:href='/users/steve'/>
</users>

等等.

我可能在这里无知,但是不应该有某种标准规定如何格式化到其他资源的链接,所以没有任何关于如何格式化数据的知识？换句话说,应用程序A1的API的爬虫X可能不适用于应用程序A2的API,因为A1将其链接格式设置为与A2不同.

在上面,我只讨论XML媒体类型.当您使用JSON时,该领域还有更多版本.

为什么REST没有指定如何格式化资源相关资源的链接？

在我们的项目中,可以通过POST或PUT请求发送书籍结构(XML,JSON,...)来添加书籍.例如,在XML中,书籍结构如下所示(简化):

<book>
    <title>My Book</title>
    <author>John Q.</author>
</book>

当这本书插入我们的后端数据库时,会自动添加一些自动生成的属性,例如创建日期,提交书籍的用户ID,标识符,......

通过GET检索书籍时,这些附加属性包含在书籍定义中:

<book>
    <title>My Book</title>
    <author>John Q.</author>
    <info>
        <creation_date>2011...</creation_data>
        <user_id>48</user_id>
        <identifier>my_book_john_q</identifier>
    </info>
</book>

这基本上意味着新/编辑的书籍(=从客户端到服务器)的XML方案与检索到的书籍(=从服务器到客户端)不同.这让事情变得混乱.

可能性是使这些附加属性在不同的URI中可用,例如:

http://server/books/:id/             -> returns the short version
http://server/books/:id/information/ -> returns the generated properties

这种方法的缺点是需要两个单独的请求才能获得所有数据.

你会如何解决这种不一致？