What is the best approach to version WebAPIs?
I am building an API from scratch and I would like to ensure that it will version gracefully in the future. I am envisioning something like mysite.com/api/v2/...
One approach I see is to create a separate project (web app) for each version of API. But perhaps there are better ways to do it?
Thank you for your ideas.
Including version number in the URL is the standard approach as I explained in this post (I do not repeat the content): Implementing versioning a RESTful API with WCF or ASP.Net Web Api
You do not need to create a completely new project although you can. The problem that you will be facing with a single project is that there will be collision of names:
/api/v1.0/Car/123
and
/api/v2.0/Car/123
both will point to CarController while you can have only one of those. The solution would be to implement your own IHttpControllerSelector and register with the DependencyResolver. This implementation will look at the version number and perhaps find the type based on the namespace.
UPDATE
I do not intend to start a REST controversy here. But as #DarrelMiller points out, here is an older discussion on the same subject discouraging my suggested approach:
How to version REST URIs
I personally think URL versioning is the way to go.
You will need to create your own implementation of IHttpControllerSelector. The best way is to base this implementation on Microsoft's IHttpControllerSelector. Then you can decide in your IHttpControllerSelectorif you want to version by URL or by content-type.
The most basic implementation directly implements IHttpControllerSelector and just implements the SelectController method but performance reasons it is better to implement some caching around it.
For finding the Controller you simple the IHttpControllerTypeResolver instance you can get using HttpConfiguration.Services.
I've used something like this: http://damsteen.nl/blog/implementing-versioning-in-asp.net-web-api. Also put some code on Github: https://github.com/Sebazzz/SDammann.WebApi.Versioning.
Related
I'm new to Laravel & I wanted to know something about it's feature that calls Contracts.
(If my question not in place, let me know why, and don't just downvote it).
So from what I red in Laravel Documentation and say on Laracasts videos, I understood that contracts they are only interfaces for class implementation.
So what it's good for? That if I or someone else will implement those interfaces will all need to go by the interface and then I dont need to change my code at all?
Is that the reason why Laravel uses it's implementation as a contracts ?
Also I wanted to know, to achive the implementation I must bind the implementation to a contract?
Yes, I think your understanding is mostly correct. I will try to explain with an example. Let's say you have a PackageDeliveryServiceContract that has some methods like trackPackage, getShippingCost.
You create a FedexDeliveryService to adhere to the contract and implement those methods.
In your controller, you can just inject PackageDeliveryServiceContract and start using it right away. (are you familiar with laravel's dependency injection?).
Let's say later you decide you no longer want to ship with Fedex and use UPS instead. Then you can create UPSDeliveryService that also adheres to that contract.
Now, all you need to do is change your binding from FedexDeliveryService to UPSDeliveryService and you don't need to make any changes to your controller code.
Typically you will create the binding between contract and implementation inside a service provider such as app/Providers/AppServiceProvider.php
I am currently evaluating possibilities, how to write/generate level2+ rest API. I came across karharis and i pretty like the concept and the whole idea how its done seems sound to me. But I have not found answers to these questions:
How to handle security properly. I can imagine that it might get tricky, as JSON api supports traversing to some extent. (out app will run in spring environment, so I suppose that we might use spring-security, but I do not know, if we will encounter some hidden traps)
API versioning. I havent found any clues how to handle API evolution. Are there any already supported options (content negotiation, path variable, query parameter...?) or do we need to hack it ourselves?
Thanks in advance!
I am writing a Padrino app which will expose a few services via REST apis. I need to version the apis. I found this answer which explains how to version an api such that the version is embedded in the uri. I would rather put my version info in the Accept header or some other HTTP header (let's not go into the whole embed-in-uri vs put-in-header debate for now). Is there an idiomatic way of implementing this in a Padrino controller? I would like to avoid littering version checks in all my routes. Is there any way I can put the check in a central place (DRY) or - better still - let Padrino take care of this for me with some magical directives?
Try to implement (ofc, w/o 'v1' in url) this.
Also found that. It should work since Padrino is the little bro of Sinatra.
Can't test for the moment. Please keep me aware !
I am not using any of asp.net Authentication in my code. It is handled by an outside library. I get back a success or failure from the function. So all the work is done for me.sCould I get some examples of how I would implement this in MVC3. I know a little, I have had 2 weeks experience.
Thanks.
AuthFunction("UserName", "password");
You need to implement your own MembershipProvider. The ValidateUser method will use AuthFunction method from your library.
This tutorial should be good. Just skip the repository things because those are already implemented by your library. Carefully check the configuration section at the bottom of the tutorial.
I am currently working on a ASP.NET MVC 3 project and I am setting up the solution file on VS2010.
I am not sure of what is the standard approach. I am using the following approach
Company.Dept.Data (contains the dbml file - Data Model)
Company.Dept.Business (Business logics)
Company.Dept.Web (contains ASP.NET MVC3 webapplication)
The first two are class libraries and the last one is MVC3 web application.
Anyother recommendations?
There is no single "standard" approach. It all depends on your project and what problems you are trying to solve with the software. Your proposed structure of having 2 class libraries and 1 web project is one way to go for sure.
If you are going to do any kind of Dependency Injection using an Inversion of Control container, you might also want to consider having an "API" project for interfaces and an "Impl(ementation)" project for concrete classes that fulfill the interface contracts.
To echo danludwig, there really is no standard. I prefer breaking up libraries and namespaces according to functionality. Company.Db is my library for interacting with the database, Company.Mail are my wrappers around the Postmark mail service, etc.
I then tend to group like libraries into single repositories. So the 'storage' repository in source control holds Company.Db, Company.Caching, Company.FileStorage, etc. I have another repository 'messaging' that holds Company.Mail and Company.SMS (for interacting with Twilio to send text messages). When I branch out with new apps or new services (maybe a WCF endpoint for mobile clients), I can just pull down the 'messaging' repository, and I have all my class libraries for communicating with the user.
An application then looks like
Company.Application.Webite
\Libraries\Messaging
\Libraries\Messaging\Company.Mail
\Libraries\Storage
\Libraries\Messaging\Company.Db
\Libraries\Messaging\Company.Caching
\Libraries\Web
...
Company.Application.Wcf
\Libraries\Messaging
\Libraries\Storage
\Libraries\Messaging\Company.Db
\Libraries\Messaging\Company.Caching
...
This way, whether someone registers via the site, or via the mobile app, Company.Mail.MailServices.SendWelcomeEmail() sends the exact same welcome email, and there's no code duplication.
Whether this works for you, or even makes sense, who knows. I've also changed this scheme a hundred times, trying to find a layout that works with my development style/workflow. I wouldn't worry or stress too much about it, because whatever you pick, you're going to find things you like about it, and you'll find things you hate about it. I sometimes fall into the trap of spending more time trying to make everything "perfect", than to just code and change things I don't like.