We're currently using MvcContrib.Routing.MvcRoute for our routes, but it's marked as Obsolete in version 3.0.51.0. Was the fluent API replaced by something or just abandoned?
According to the changelog:
Deprecated MvcRoute and RegexRoute. Not maintained in nearly 2 years
Simply use the standard Route class in Mvc. Or if there is some functionality that you depend upon you could continue using it but bare in mind that the support for it has been dropped.
And here's the response from Jeremy:
The only real issue with MvcRoute is that it doesn't work with areas,
which limits its usefulness. I'm not intending to remove it anytime
soon, but I think MVC's built in MapRoute extension methods are
probably a better choice going forward.
Related
I'm trying to use T4MVC to create strongly typed links to WebApi endpoints, and while it does generate helpers for my ApiControllers, there's no method for creating links. The generated controllers have ViewNames, but no action methods. I guess this is because ApiController's don't return ActionResult's, but what do I need to be doing instead to create these links?
It is not supported today, but please check out this thread which has some good amount of discussion about it. Feel free to reply over there to add to it.
Still doesn't seem to be supported by the end of 2015.
If it's URL generation that you're concerned with, then take a look at Drum if you're using attribute routing in Web.API 2+. And if you've got routes set up in your application startup (Web.API 1) then it appears Hyperlinkr will be helpful.
If you need other things (like a hard-coded parameter list) then you're still out of luck.
Disclaimer: I've not used either
I'm developing a rails app, it's a regular site, but I need to develop an API, so I was reading and trying some stuff, the options that I've thought are (others are welcome):
Versioning the API and separate the API from the controller.
Pro: Clean and separate stuff. Cons: the need to handle 2 controllers for the same task.
Not versioning and keep everything in the same controllers, views can be done with jbuilder. Pro: not really easy way to version it. Cons: harder to expose only parts of the app. harder to route stuff like in an versioned way.
I really want to avoid duplication, but I need some way to avoid that, and make some nice routes like in a versioned way, I don't want to have more than 1 controller for some type of object, in a versioned way if you have 3 versions you'll end up with 4 controllers, that is a lot to maintain.
Please correct me if I'm wrong, and hope to get some good answers :)
Thanks.
Versioning your API is the best route to take.
If you have 4 versions, 1 controller, you still only need to maintain 2 controller (the one in the web facing application, and the most recent version of the API.)
If you have write access in your API, you would be able to take advantage of your own API in your application and not need to create a new method in both the API and in the main application (AJAX).
It is possible that your filters are different. You may need different types of authentication for the API and the main application.
The biggest argument for versioning would probably be that if you have anyone other than yourself consuming the API, their application would not break the day you deploy your changes.
Besides, you should keep to the 'thin controllers, fat models' mentality. That would prevent a lot of duplication with that alone.
I always code api within their own namespace because these points could be very different from the main app:
format rules
auth
rescue
versioning
before / after filters
Even if you have duplication in controllers, there should not be much code, and I cant see why it would be a big deal. Actually it could even force you to abstract your code and have thin controllers.
I am thinking of using upshot.js along with Knockout in one of my very important projects. I do not see any documentation or any activity around upshot. Before I commit to this decision, is this project still active?
If the entire asp.net stack is now open and one can see what is getting committed to repository, why this small library is still not on codeplex or github for community to see?
I hope this is still on radar of asp.net team.
According to this blog post, Upshot is officially dead:
http://www.riaservicesblog.net/Blog/post/WCF-RIA-Services-is-Dead-Long-Live-WCF-RIA-Services.aspx
The author points to BreezeJS as an alternative:
http://www.breezejs.com
Upshot is officially dead.
"Earlier this year the Beta version of Visual Studio 2012 included a template that was designed for building “single page applications” using Upshot.js and a special Web API-based DataController that provided support for insert, update, and delete operations using the unit of work pattern with transaction support. We are not currently continuing work on that template or Upshot.js. We want to first focus on improving the development experience with existing popular JavaScript libraries and in future versions we will revisit this decision and see if additional libraries are needed to round out the SPA experience."
http://aspnetwebstack.codeplex.com/wikipage?title=Roadmap
Give a shot to JayData at http://jaydata.org, it has JavaScript Language Query and JavaScript CRUD capabilities with change tracking, batches and a lot more. What it offers over BreezeJS is its provider agnostic architecture and a number of providers that you can use out of the box: OData, webSQL, IndexedDB, localStore, Facebook and YQL.
JayData plays nicely with NodeJS and let you consume OData from a JavaScript based middletier.
Also you can use JayData not only to consume but also to provide OData if you are using it on the server side with NodeJS and mongoDB.
The ASP.NET team haven't finished the official release of ASP.NET SPA in time to ship with the final ASP.NET MVC 4 release but they are still working on it.
You can find the source code for ASP.NET SPA and follow the development effort on the ASP.NET CodePlex site:
ASP.NET SPA Source Code (to look at the upshot stuff click Browse and expand src/SPA/upshot
ASP.NET SPA Discussions
The general lack of documentation is caused by the fact that there haven't be an official release yet.
Speaking for my company - we used exactly the same combination (Knockout + Upshot) and after sweating a lot of blood, we decided to get rid of Upshot and replace it with JQuery's ajax calls. Much more transparent and much more bugfree. However, much more code, too.
Back in February the authors of Upshot promised they would put documentation on in a week or so and since then I've heard nothing of them. If you want my opinion, I think this project has already been buried or indefinitely postponed.
Accodding to what is said on the discussions(see http://aspnetwebstack.codeplex.com/discussions/topics/5321/asp-net-single-page-application) on SPA, the whole SPA strategy would change, so I think the final version o SPA or whatever will replace it will be quite different from the actual bits...so I don't know if it is a good move continuing using the actual version...that at my bets knowledge is not compatible with Mvc 4 RTM.
I am the author of the Mvc Controls Toolkit there we implemented some js functions to help querying OData, and to update entitiess that are on the client side. They handle validation errors(both client side and server side), return to client principal keys created on the server, do changes tracking (to send to the server just changed entities) and allows undoing changes done on the client side. They handle also one to many relations. Moreover, updates are handled not only with WebApi controllers but also with normal controllers.
Give a look to this first tutorial: http://dotnet-programming.com/post/2012/04/03/Mvc-Controls-Toolkit-Support-to-Mvc4-WebApi.aspx
and then refer to the other tutorilas linked.
I'd like to use WebAPI as my API technology to:
Allow approved companies to enter/retrieve data in my systtem
Create a standard interface for my company's iOS/Android/etc. applications
Does anyone know of best practices for, and mechanisms used to implement, versioning of interfaces. Specifically, I don't want to break backwards compatibility if I make updates to my API. I'd like to know what versioning schemes people use and if WebAPI has any built in mechanisms supporting versioning without the need to set up routes/paths every time a new version is released. Any thoughts would be appreciated.
Update
After performing some research I think I know what I want to do, I'm not sure how to do it. Ideally during content negotiation I would like to use a media type passed by the user to specify which version of the API should be used (rather than hard-coding the URL) and hit the corresponding controller.
If you don't want the version to be included in the Url, the way to go is probably to implement IHttpControllerSelector. This blog post should give you a good starting point: Implementing API versioning in ASP.NET Web API
I recommend you take a look at Peter Williams' series of blog posts on versioning REST services. They explain the what and why. For the how, check out Mike Wasson's tutorial on how to create a custom media formatter.
Some of the responses to a question I asked today earlier today have caused me to question my assumption that it should be possible to use Rails in a non-MVC manner as opposed to simply using a microframework like Sinatra for barebones non-MVC-type apps.
Has anyone used Rails in a non-MVC manner without it causing major problems or could you imagine an appropriate case for doing so?
What do you want to build? If you want to use all of rails, MVC is the way to go. Even a tiny framework like camping is MVC.
If you just need a part of it, most commonly, activerecord, you can happily use it any way you want.
But rails itself is MVC all the way, you'd be working against it trying to coerce it into another paradigm.
Yes, it is possible, but Rails framework architects made it difficult to stray from the MVC path for a reason. They want to encourage 'good' behavior and discourage 'bad' behavior.
Not only should you use MVC with Rails, but MVC is a good idea in general.
If you're just writing some one-off-ish app then you might look at Rails Metal or, as you already mentioned, Sinatra.
Again, why do you WANT to avoid MVC? MVC is an excellent thing