简而言之，做 REST 仅一半只是就像根本没有真正去做一样。 你只是将你的东西转移到不同的管道上，错过了将简化的 API 转换为状态机、语义和核心实现解耦，以及使用构建网络的原则（因此我会说你'你背后有相当成熟的想法）、统一的界面以及将 URI 作为建模的一部分。
我知道现在流行这样一种说法：你可以挑选，一切都只是选择。 它不是。 REST 只有充分利用它才有意义，但要说服你真正进行伸展运动你的大脑再远一点，做一些聪明的事情，我只能挑战你消除 FUD（这都是关于 RPC 的，只有 GET 和 POST 是必需的，你不需要全部，相当于 JSON、SOAP 等，等），并更明智地了解如何制作应用程序。 是的，我敢说你们都敢！
As a die-hard RESTafarian I'd say use HTTP (the REST protocol in question) to its full extent. Why? Well, I'll show you two snippets from an email exchange I had yesterday with a good friend of mine who's seriously clever (and used to be a professor of IT, still lectures, still kicks ass wherever he goes) ;
Yesterday I passed an important milestone for my mappodrhom application: I can now launch long-running background computations into a worker pool. When they finish, the workers POST back their results directly into the REST resources. Which triggers more background processing, all controlled by a dependency graph.
And the interesting aspect is that this RESTful backgrounding is actually independent from my particular application. But I am currently too tired to completely grasp the consequences :-)
The consequences in question are huge (it's a REST framework with lots of little stacks and events and services and apps, all with their own discoverable URIs, all with the same unified interface), and in terms of extensibility and scalability it is simply unmatched in its simplicity. If your application is a dinky little thing that will never travel places or meet hot chicks, yeah maybe you don't need it. But then, I've said the same, and all of a sudden found myself on a train to Paris with a cute girl that is a secret spy for the Russians, and well, one thing led to another...
Here's my reply, with some of my own experiences ;
I think this sounds (pardon my French) f***ing awesome! I'm experiencing similar things with my own REST stuff, where because the middle layer is so thin and transparent, I can just extend things the way I need them without worrying too much about the infra-structure. It's such a freedom, such a kick-ass cool thing that my brain is about explode, and a worrisome curiosity to why more aren't doing it?
In short, doing REST only half-way is just like not really doing it at all. You're just shifting your stuff over a different pipeline, missing out on a simplified API into a state-machine, semantics- and implementation decoupling at the core, working with the principles that built the net (and hence I'd say you've got rather proven ideas behind you), the unified interface, and having URIs as part of your modeling.
I know it's popular to say that you can pick and choose, that it's all just options. It's not. REST only makes sense by using it fully, but as to convincing you to actually stretch your brain a bit further and do something clever, I can only dare you to cut through the FUD (that it's all about RPC, only GET and POST necessary, you don't need it all, equivalent to JSON, SOAP and other ilk, etc.), and be smarter about how you make applications. Yeah, I dare you all!
Unless you are going to take advantage of hypermedia then I wouldn't bother trying to conform to the REST constraints. Hypermedia is the piece of the puzzle that makes the system greater than the sum of its parts.
You are free to pick and choose which of the REST constraints you want to respect in your architecture, just note that to be able to call the end result RESTful, the only optional constraint is "code-download".
It's an option amongst several for exposing a web application as a web service with a well-defined API. Other options include:
No API - The application has no real way to be used as a component in other distributed systems
SOAP - An XML format for defining API remote calls
JSON - A compact format for information exchange that can be built on to create a custom API format (or used to build a REST system if you wanted)
Many other forms of remote procedure calls and information exchange mediums.
REST has a nice ideal behind it, but that doesn't mean you have to provide a REST API for your application. If the gain isn't worth the extra effort, don't bother.
这是一个推荐。 我很高兴你没有讨论你需要如何休息，因为有一种叫做“高休息”和“低休息”的东西。 您可以通过谷歌搜索获得更多信息。 我认识的一些行业资深人士不太关心这一点，但我确实发现尽可能接近 html 和 http 从长远来看会对您有所帮助并简化许多事情。
It is a recommendation. I am glad you did not go into how RESTful you need to go into as there is something called Hi-Rest and Lo-REST. You can get more information from googling. Some industry veterans I know do not much care about this, but I do find staying as close to html and http will help you in the long run and simplifies many things.
I would submit that it's a nice to have but not a must. In my experience adding this architecture increases the scope and complexity of the project, but it does add a degree of elegance to the whole. I would say if you've got the time and budget on the project, go for it, if not don't worry about it.
One (of the many) things to consider with service API's is the ease in which they can be consumed by your end user. REST is gaining a very strong tooling presence.
By far the largest dev group out there is the .NET dev group, and with ADO.NET for services (Astoria) consuming REST using Linq is very simple and very elegant.
发布评论
评论（6）
作为一个顽固的RESTafarian我会说使用HTTP（有问题的REST协议）充分发挥作用。 为什么？ 好吧，我将向您展示昨天我与一位好朋友的电子邮件交流中的两个片段，他非常聪明（并且曾经是一名 IT 教授，仍然在讲课，无论他走到哪里仍然很出色）；
所讨论的后果是巨大的（它是一个 REST 框架，有很多小堆栈、事件、服务和应用程序，所有这些都有自己的可发现的 URI，都具有相同的统一接口），并且在可扩展性和可扩展性它的简单性是无与伦比的。 如果您的应用程序是一个很小的小东西，永远不会去旅行或遇到辣妹，是的，也许您不需要它。 但后来，我也说了同样的话，突然发现自己在去巴黎的火车上，身边有一个可爱的女孩，她是俄罗斯人的秘密间谍，好吧，一件事导致了另一件事......
这是我的回复，结合我自己的一些经历；
简而言之，做 REST 仅一半只是就像根本没有真正去做一样。 你只是将你的东西转移到不同的管道上，错过了将简化的 API 转换为状态机、语义和核心实现解耦，以及使用构建网络的原则（因此我会说你'你背后有相当成熟的想法）、统一的界面以及将 URI 作为建模的一部分。
我知道现在流行这样一种说法：你可以挑选，一切都只是选择。 它不是。 REST 只有充分利用它才有意义，但要说服你真正进行伸展运动你的大脑再远一点，做一些聪明的事情，我只能挑战你消除 FUD（这都是关于 RPC 的，只有 GET 和 POST 是必需的，你不需要全部，相当于 JSON、SOAP 等，等），并更明智地了解如何制作应用程序。 是的，我敢说你们都敢！
As a die-hard RESTafarian I'd say use HTTP (the REST protocol in question) to its full extent. Why? Well, I'll show you two snippets from an email exchange I had yesterday with a good friend of mine who's seriously clever (and used to be a professor of IT, still lectures, still kicks ass wherever he goes) ;
The consequences in question are huge (it's a REST framework with lots of little stacks and events and services and apps, all with their own discoverable URIs, all with the same unified interface), and in terms of extensibility and scalability it is simply unmatched in its simplicity. If your application is a dinky little thing that will never travel places or meet hot chicks, yeah maybe you don't need it. But then, I've said the same, and all of a sudden found myself on a train to Paris with a cute girl that is a secret spy for the Russians, and well, one thing led to another...
Here's my reply, with some of my own experiences ;
In short, doing REST only half-way is just like not really doing it at all. You're just shifting your stuff over a different pipeline, missing out on a simplified API into a state-machine, semantics- and implementation decoupling at the core, working with the principles that built the net (and hence I'd say you've got rather proven ideas behind you), the unified interface, and having URIs as part of your modeling.
I know it's popular to say that you can pick and choose, that it's all just options. It's not. REST only makes sense by using it fully, but as to convincing you to actually stretch your brain a bit further and do something clever, I can only dare you to cut through the FUD (that it's all about RPC, only GET and POST necessary, you don't need it all, equivalent to JSON, SOAP and other ilk, etc.), and be smarter about how you make applications. Yeah, I dare you all!
除非您要利用超媒体，否则我不会费心去尝试遵守 REST 约束。 超媒体是拼图中的一块，它使系统大于各个部分的总和。
您可以自由选择要在架构中遵守哪些 REST 约束，只需注意，为了能够调用最终结果 RESTful，唯一的可选约束是“代码下载”。
Unless you are going to take advantage of hypermedia then I wouldn't bother trying to conform to the REST constraints. Hypermedia is the piece of the puzzle that makes the system greater than the sum of its parts.
You are free to pick and choose which of the REST constraints you want to respect in your architecture, just note that to be able to call the end result RESTful, the only optional constraint is "code-download".
它是将 Web 应用程序公开为具有定义良好的 API 的 Web 服务的多种选项之一。 其他选项包括：
REST 背后有一个美好的理想，但这并不意味着您必须为您的应用程序提供 REST API。 如果收获不值得付出额外的努力，那就别费心了。
It's an option amongst several for exposing a web application as a web service with a well-defined API. Other options include:
REST has a nice ideal behind it, but that doesn't mean you have to provide a REST API for your application. If the gain isn't worth the extra effort, don't bother.
这是一个推荐。 我很高兴你没有讨论你需要如何休息，因为有一种叫做“高休息”和“低休息”的东西。 您可以通过谷歌搜索获得更多信息。 我认识的一些行业资深人士不太关心这一点，但我确实发现尽可能接近 html 和 http 从长远来看会对您有所帮助并简化许多事情。
It is a recommendation. I am glad you did not go into how RESTful you need to go into as there is something called Hi-Rest and Lo-REST. You can get more information from googling. Some industry veterans I know do not much care about this, but I do find staying as close to html and http will help you in the long run and simplifies many things.
我认为拥有它是件好事，但不是必须的。 根据我的经验，添加此架构会增加项目的范围和复杂性，但它确实为整体增添了一定程度的优雅。 我想说，如果你有这个项目的时间和预算，那就去做吧，如果没有，也不要担心。
I would submit that it's a nice to have but not a must. In my experience adding this architecture increases the scope and complexity of the project, but it does add a degree of elegance to the whole. I would say if you've got the time and budget on the project, go for it, if not don't worry about it.
使用服务 API 需要考虑的（众多）事情之一是最终用户使用它们的难易程度。 REST 正在获得非常强大的工具地位。
到目前为止，最大的开发组是 .NET 开发组，并且通过 ADO.NET for services (Astoria) 使用 Linq 来使用 REST 非常简单且优雅。
One (of the many) things to consider with service API's is the ease in which they can be consumed by your end user. REST is gaining a very strong tooling presence.
By far the largest dev group out there is the .NET dev group, and with ADO.NET for services (Astoria) consuming REST using Linq is very simple and very elegant.