什么是今天.NET实现一个RESTful架构的最佳方式？ [英] What is the best way to implement a RESTful architecture in .NET today?
问题描述
在你提到它我知道这个问题已经被问过，但不自启动WCF4的！
Before you mention it I am aware that this question has been asked before but not since the launch of WCF4!
所以，大量的阅读后，我已经决定，一个RESTful架构是开始的数据提供API前进的方向。考虑到发行WCF 4，ASP.NET MVC 2和WCF REST入门套件，什么是现在就开始实施一个RESTful架构的最佳方式？
So, after a lot of reading I've decided that a RESTful architecture is the way forward to begin a data providing API. Considering the release WCF 4, ASP.NET MVC 2 and WCF REST starter kit, what is the best way to begin implementing a RESTful architecture NOW?
我：
我很熟悉ASP.NET MVC，所以我会觉得很舒服那里。我的WCF的知识，但缺乏。
Me: I am very familiar with ASP.NET MVC so I'd feel quite comfortable there. My knowledge of WCF, however, is lacking.
所以 WCF4或ASP.NET MVC吗（或别的东西，像WCF其余入门套件）？具体来说，我在寻找：
So WCF4 or ASP.NET MVC? (or something else like the wcf rest starter kit)? Specifically I'm looking for:
- 易于实施
- 我知道ASP.NET MVC，不WCF。 WCF是值得学习曲线？
- 是WCF4矫枉过正REST或将ASP.NET MVC在某些时候达不到？
推荐答案
其实我已经实现或现在使用的发布选项，所有3所以我给我的起飞。现在，您已经澄清了您寻找一点点的比较容易回答。
I've actually implemented or am currently using all 3 of the posted options so I'll give my take. Now that you've clarified what your looking for a little its easier to answer.
的OData
的OData内部应用程序是伟大的，当：
OData is great for internal applications when:
- 您是在服务器和客户端。
- 您正在使用实体框架。
- 您没有在模型中使用的继承，并且不希望查询的子集。
的OData是真棒，因为你可以在客户端使用IQueryable的。这带有一定的局限性，虽然。这两个把我的头顶部的包括你继承模型时是有点尴尬，你一个< href=\"http://stackoverflow.com/questions/3390761/collection-exists-criteria-in-wcf-data-services\">can't做嵌套集合的。
Odata is awesome because you can use IQueryable on the client side. This comes with some limitations though. The two off the top of my head include that you working with inherited models is a little awkward and you can't do nested collections.
有也有不真正了解href=\"http://stackoverflow.com/questions/2775473/supported-linq-for-wcf-data-services\">支持
There is also an issue with not really knowing what the supported LINQ capabilities are.
我推荐的OData是你绝对需要一个服务层，只希望做简单的CRUD操作它们。每OData的问题，主要的问题导致硬墙面你就不能得到解决的时候。客户消费code是真正最好的部分，如果你不使用C＃来消耗它可能不值得。
I'd recommend OData is you absolutely need a service layer and only expect to do simple CRUD operations with them. The main problem with every OData problem results in a hard wall you just can't get around sometimes. The client consumer code is really the best part and if you aren't using C# to consume its probably not worth it.
另外，而不使用EFS自动元数据支持，你会写只是code相同数量以符合您的架构消费者可能会或可能不会喜欢写作反对。虽然是Rails包装器的OData所有这一切都是相对较新。我没有看到的OData在野外但除了真正的大MS合作伙伴。
Also without using EFs auto metadata support you'll be writing just the same amount of code to conform to a schema your consumers may or may not enjoy writing against. While there is a Rails wrapper for OData all of this is relatively new. I don't see OData in the wild yet besides really big MS partners.
的OData验证和过滤也是pretty裸露的骨头ATM。你会自己来写了很多相关的权限code，如果你需要限制的数据。如果你想SELECT * FROM表由权限限制是ppared编写一些尴尬code $ P $。
OData authentication and filtering is also pretty bare bones ATM. You'll be writing a lot of permission related code by yourself if you need to limit data. If you ever want SELECT * FROM TABLE to be limited by permissions be prepared to write some awkward code.
MVC 2
MVC是pretty好让RESTful服务。你有动词的支持和返回JSONResult 是容易的它可以。唯一的潜在的缺点是您的编码有很多错误处理自己和所有的视图模型应该从基类，显示的状态codeS和错误消息继承。
MVC is pretty good for making a RESTful service. You have verb support and return JSONResult is as easy at it can be. The only potential downside is your coding a lot of the error handling yourself and all of your view models should inherit from a base class that shows status codes and error messages.
您可能还需要调整视图引擎一点取决于你想多么花哨或约定驱动您的留言回复是。巨大的效益，以MVC是其本身的可扩展的，你几乎可以任何你想要做的。我是大进相结合的形式/ Ajax调用/休息服务纳入同一个控制器的动作。一旦实施，得到了相同的操作三种口味。这将是很难做出MVC功亏一篑，因为它可以被扭曲做几乎任何事情你需要。
You also may want to tweak the view engine a little depending on how fancy or convention driven you want your message replies to be. The HUGE benefit to MVC is its very extensible and you can do almost whatever you want. I'm big into combining forms/ajax calls/and rest services into the same controller action. Implement once, get three flavors of the same operation. It would be hard to make MVC fall short because it can be twisted to do almost anything you'd need.
有一个很大的好处，以一个MVC服务是您可以在该得到的服务一起部署的应用程序偷偷一点点管理界面。非常方便不能有两个站点进行部署。
A big benefit to an MVC service is you can sneak a little admin UI in a the application that gets deployed along with the service. Very handy to not have two sites to deploy.
WCF REST
所以我只使用在非常有限的能力WCF休息，似乎...确定...我已经使用WCF为3年，我总是不满意，这是多么令人沮丧复杂扩展它。就像ODATA如果你去了因循守旧你会碰到密封类和功能pretty快速的unextensible洞穴。这是直接的对比可扩展的MVC的数量。
So I'm only using WCF rest in a very limited capacity and it seems... ok... I've used WCF for 3 years and I'm always unhappy with how frustratingly complex it is to extend it. Just like ODATA you'll run into sealed classes and unextensible caverns of functionality pretty quick if you go off the beaten path. This is in direct contrast to MVC's amount of extensibility.
另一个问题是你对WCF的顶部，所有与它一起去疯狂的建筑。我一直说，它需要一个博士学位有效地使用WCF。里克施特拉尔有大约WCF REST 的痛点的好文章。不知道如果事情发生了变化，但它值得一读。
The other problem is your building on top of WCF and all the insanity that goes along with it. I've always said it requires a PhD to use WCF effectively. Rick Strahl had a good article about the pain points of WCF REST. Not sure if things have changed but its worth a read.
WCF REST看起来非常有前途，我用它，现在我不知道有足够的了解它推荐。
WCF REST looks really promising and I'm using it right now I just don't know enough about it to recommend.
的要点的
-
如果你不知道你的消费者的话，我会假设你不知道你的API。直到你有一个用例，可以code反对它不建立一个服务。
If you don't know your consumers then I'd assume you don't know your API. Don't build a service until you have a use case and and can code against it.
MVC是最可扩展的，如果你熟悉的东西在幕后是如何工作的，你很可能会比实现硬盘来扩展MS东西一样的OData和WCF更好。
MVC is the most extensible and if you are familiar with how things work under the covers you'll probably be better off than implementing a hard to extend MS thing like OData and WCF.
所有的大男孩像Facebook，亚马逊，贝宝，易趣有真的不符合任何已知的模式或模式类似的OData的API。你REST的服务真的是你用它来做什么。这涉及到＃1。专心很容易使消费者与第一工作。
All of the "big boys" like Facebook, Amazon, PayPal, Ebay have APIs that don't really conform to any known pattern or schema like OData. Your REST service is really what you make of it. This relates to #1. Concentrate on making it easy for a consumer to work with first.
这篇关于什么是今天.NET实现一个RESTful架构的最佳方式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
