首页 文章

REST Web服务,仅用于数据库访问?

提问于
浏览
2

我一直在阅读REST Web服务,并希望实现自己的休息服务 .

我见过的互联网上的所有例子都与数据库访问有关 . 但我想要实现的目标与访问数据库无关 .

我想创建一个REST服务,它允许将大字符串和各种其他参数传递给资源,然后返回一个xml结果集 . 在数据库中没有创建或更新任何内容,也没有从数据库中检索任何内容 . 它将数据传递给复杂的处理过程,然后返回结果 .

我的问题在于我使用什么VERB?

我觉得我应该使用GET动词与最佳实践保持一致,但有时候查询可能会非常大,并且在查询字符串上传递它是实际的 .

这让我有了POST . 这似乎符合我想要实现的目标,但我认为它再次脱离了REST最佳实践!

是否只在要与数据库交互时使用REST?

我应该放弃使用rest并创建SOAP服务的想法吗?

更新我的REST服务是分析文章并返回给定文章的关键字报告 . 鉴于此,资源是“关键字”,对此的POST将返回完整报告 . 我当时正在考虑第二个uri的关键字/推荐,一个POST将返回一些推荐的关键短语提交的文章 . 这符合REST吗?

4 回答

  • 0

    如果事实REST与数据库无关,则REST不需要数据库 .

    您描述的场景正是POST的目的 . 引用最新版本的HTTP specs

    POST方法用于请求源服务器接受请求中包含的表示作为目标resource.resource要处理的数据 .

    你可以这样做:

    POST /ArticleProcessor
    Content-Type: text/plain
    

    发送您的文章文本,响应可能是:

    Status: 200 OK
    Content-Type:application/xhtml
    
    <html>
    <title>Results of keyword processing</title>
    <body>
    <a rel="FullReport" href="/reports/2343434/full">Full Report</a>
    <a rel="TopKeywords" href="/reports/2343434/top">Top Keywords</a>
    </body>
    </html>
    
  • 0

    请记住,REST类似于SOAP,XML-RPC等,只描述了一个接口,而不是提供该接口的应用程序的实现 . 没有理由,为什么REST只应该用在CRUD数据库场景中 .

    我会使用以下方法解决您的问题:

    让客户端通过带有POST参数("large string and various other parameters")的 POST 将其数据发送到通用URI(例如 http://example.com/processor )并返回结果资源的URI(例如 http://example.com/results/<unique-id> ) . 客户端现在可以 GET 从那里"complex processing procedure"的结果 .

  • 1

    你可以采取一粒盐的“最佳实践”的东西 . 我不确定是否有人真正关心POST是否影响数据库,只要它能正确执行您记录的任何操作 .

    只要您的用户知道会发生什么样的行为,您就可以了 .

  • 4

    我会坚持使用REST,如果你真的有,也可以使用POST方法 . 没有REST不仅适用于数据库 . 然而,在没有SOAP的情况下使用它应该非常简单 . SOAP尝试执行的许多任务(例如身份验证)都可以通过直接http完成 . 这个想法是REST轻巧,反应灵敏,易于理解和使用 . REST我会把它描述为与一位忘记你是谁的老姨妈的谈话 . 也许当您查询REST应用程序时,您可能需要将其分解为名词和动词,例如针对人员资源或场所资源的查询,而不是尝试同时查询场所和人员,将两者划分为询问每个资源您的查询 . 它确实使协议变得如此繁琐,但如果你真的关心网络流量,那么我会使用XML-RPC或SOAP .

相关问题