2010-11-06 68 views
3

目前我正在尝试构建一个宁静的HTTP后端框架。仅使用四种HTTP方法创建任何类型的restful API?

我读过一本书,叫做“平安web服务”,并启动了一些脑力上的这个区域。

我现在为什么资源导向架构是一件好事,但仍有模糊的部分我不明白一个更大的图片。我会试着解释我的想法,看看有人能让我更聪明。

难道不能说所有东西都是物体。汽车,钢笔,书籍,甚至抽象的东西,如想法和概念都可能成为一个对象。因为单词对象只是“某物”的人类发明。

难道你不能说每一个“东西”都是一种资源。硬币,电脑甚至债务都可能是一种资源。但问题在于谁。债务是一种资源,但不是欠谁的人,而是欠他的人。与人类残留物相同。他们是资源,但不是为我们,而是为了自然母亲,因为它需要平衡 - 进出 - 科学基础(编程)。

资源(对象)似乎是名词。如何形容词和动词?实际上似乎所有的东西都可以用名词来描述。例如。

  • 形容词:这款车是红色的
  • 名词:车内有一个红色
  • 形容词:我累了
  • 名词:我有一个疲劳
  • 动词:我杀了他
  • Noun:I create a kiss
  • 动词:I kiss her
  • Noun:I create a kiss

这意味着resource = object = noun。来自不同角度的相同“东西”。

也许有动词和不具有相当于名词的形容词,但随后即只有在人类语言中的漏洞,而不是在概念本身。

那么回到什么开始了这一切。

当我真的想到只有4个(我知道还有一些)HTTP动词 - POST,GET,PUT,DELETE - 我觉得它不能创建强大的restful API,因为它们限制了API基本的CRUD操作。但是经过一些阅读和思考之后,我意识到所有东西都只是可以创建,读取,更改或删除的资源。像内外一样,简单的规则,但是却能够创造任何东西。

但转念一想,只存在“来”与“走出去”。也许只有“创建”和“删除”。原因GET和PUT是可以用“创建读取”和“创建更改”代替的动词。

这一切只是我的母亲自然的基本的想法玩。进出,创建和删除。前者在编程领域已被广泛接受。但后者你没有听到那么多。但是,如果这是正确的,那么这意味着HTTP Restful API可以用正确的方式创建任何东西,而不是通过修改版本(将动词放在URI中,请求主体等)来创建任何东西,但仅使用POST, GET,PUT,DELETE。

我们只需将所有方法转换为资源/对象。相反的:

result = Books.search("Foo"); 

我们不得不思考:

result = Search.create(Books, "Foo"); 

你觉得这个怎么样? 考虑到这一点,是否可以使用四种HTTP方法创建任何种类的restful API? 是“创造”和“删除”自然规律的另一部分吗?

回答

1

我想你是关于一个restful API的两个不同方面。将HTTP方法简化为IN和OUT已经通过请求和响应来完成。当然,您可以将读取映射到GET和PUT来创建,但DELETE又如何?这是“PUT 0”吗?如果是这样,那么你需要逻辑来处理这种情况。

例如,当您将文档打开到文本编辑器中时,您将在操作系统中执行IN操作,并且操作系统对文本编辑器执行和执行操作。保存文档的情况正好相反。

但是,这只是简单的房屋维修机械师。当然,文本编辑器可以使用GET和OUT屏蔽IN,如“另存为”,但DELETE如何?这将需要它自己的动词或将PUT/OUT操作重载到操作系统。然后是POST,这相当于保存*。我们是否重载PUT方法来检查文件是否已经存在?为什么不把它作为自己的动词?

如果你想减少对简单IN和OUT,那么你必须重载OUT:

if(OUT){ 
    if(file_exists) update_file 
    else if(file_size==0) delete_file 
    else create_file 
} 

*我来说更理论上,当然zzzzBov是他对HTTP的规范正确后。

+0

但也许这就是我想要的。进进出出。所以我们必须使用PUT或POST来表示“in”(aka request)和GET来表示“out”(aka响应)。在这种情况下,不应该有DELETE。为了更普遍? – ajsie 2010-11-06 15:07:36

+0

如果你不想实现DELETE,那就是你的电话。如果你确实需要它,那又是另一种情况。但你仍然有创造与改变的情况。尽管它们被抽象为一种“写入”方法,但在实际写入之前它们仍然遵循不同的代码路径。 – Jeremy 2010-11-06 15:30:26

0

GET,POST,PUT和DELETE不直接与创建,读取,更新和删除相关。他们通常可以,但重要的是要注意POST和PUT都可以执行更新和创建功能。

http://en.wikipedia.org/wiki/POST_%28HTTP%29

POST方法应被用于任何 上下文,其中请求是 非幂等

这意味着POST应该用于改变服务器的任何功能(数据)状态,并且GET,PUT和DELETE应该用于任何不改变服务器状态的功能。编辑:
回答这个问题:是的。我已经看到许多解决方案用于创建带有html标头的宁静API。他们都归结为使用目录结构和正确的HTML标头。

http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services

+0

感谢您的澄清。但问题仍然存在。可以使用POST/PUT和DELETE来创建任何类型的restful API? – ajsie 2010-11-06 03:51:54

1

您可以使用只有两种方法的任何系统,GET和POST,通过等同GET =读取和POST =写。 其他方法只是帮助添加一些可见性的请求。

如果你真的想尝试和模型中的对象而言REST请求,我这样做:

result = new Search(Books,"Foo").Get(); 

但是,我不知道这个映射是特别有价值的。

+0

是的,这听起来更合乎逻辑:读取/进入/ GET,写入/结束/ POST。这是关于进出的。但是你是否同意每种方法都可以转换为一个对象?这意味着我只能使用GET和POST来创建任何稳定的API,因为我的系统上的所有内容都是可以读取或写入的对象。 – ajsie 2010-11-06 03:58:48

+0

@weng:如果你重载POST,你的系统不再是真正的RESTful。 – 2010-11-06 07:05:42

+0

@Matthew这是公然错误的。这里是罗伊关于该主题http://code.google.com/p/implementing-rest/wiki/FAQ – 2010-11-06 13:43:42

1

RESTful API本质上是某种数据存储的接口:DB,文件系统,分布式散列表,& c。这意味着你实际上不需要自定义动词(标准接口通常更好),因为你可以使用GET,PUT,POST和DELETE来完成所有的事情。

重要的是要注意,RESTful API 特别是要求使用现有HTTP方法来提取CRUD资源。而且,API不需要复杂或冗长,以便有用或者甚至是强大的。在大多数情况下,简单是你的朋友。在许多情况下,简单的结构和简单的界面比等效的复杂结构/界面做得更好。看看git,例如,它使用的数据结构非常非常简单,因此git非常非常快。

至于你的问题:是的,人们一直这样做,它的工作原理!

+0

但git有自己的动词(克隆,推,拉等)对吗?无法仅使用http动词执行混合操作(发布,获取,放置,删除),还是一个坏主意? – ajsie 2010-11-06 15:12:21

+0

Git不是RESTful API,但HTTP动词可用于创建具有类似功能的API。 – xj9 2010-11-06 15:26:28

1

但后来我想,只有“在” 和“出”。也许只有 “创建”和“删除”。原因GET和 PUT是可以用“创建读取”和“创建 更改”替换 的动词。

你可以这样做。你可以走得更远,用POST完成所有的事情。然后,您可以在HTTP请求中包含一个信封,说明您要执行的操作。您甚至可以只有一个端点,并根据您的HTTP请求的内容进行多种不同的操作。你可以有createBook,updateBook,getAllBooks等等。

而你有SOAP。作为需要构建,维护和编写SOAP和RESTful Web服务的代码的人,请自己(和其他人)倾心,并使用REST。

+1

您错过了HTTP统一界面的要点。如果您使用HTTP方法,则其行为必须符合RFC2616。然而,没有要求说你必须使用所有的方法,并没有说你是否要删除某些东西,你必须使用delete。你应该,但不一定。 POST方法适用于任何可能不安全或幂等的操作。 POST不限于“将实体添加到集合”。它几乎可以用于任何事情。 – 2010-11-06 13:52:53

+0

我并不是说你必须:我说使用HTTP动词是有意义的。在存在可以遵循RESTful模式的资源的情况下,使用动词来识别动作是有意义的。 (不要介意DELETE应该是idemopotent,但是如果资源已经被删除......?)我的观点是,使用POST进行任何操作都会破坏HTTP的透明性。 – 2010-11-07 00:35:00

+0

(呵呵,你应该对所有东西都使用POST这个想法有点讽刺,不知道是否在原来的帖子中出现过)。 – 2010-11-07 00:49:22

相关问题