As you know Visual Studio provides scaffolding for MVC and Web API controllers. In my case I'm using Entity Framework along with Web API 2.
When I add a new web api 2 controller with actions using Entity Framework, Visual Studio pretty much creates a controller with 5 endpoints.
One of these endpoints is to retrieve a single record from the database.
Here is an example for that:
// GET: api/Courses/5
[ResponseType(typeof(Course))]
public async Task<IHttpActionResult> GetCourse(int id)
{
Course course = await _db.Courses.FindAsync(id);
if (course == null)
{
return NotFound();
}
return Ok(course);
}
The above controller works fine if I call it as api/Courses/5, but it also works fine if I call it as api/Courses?id=5.
My question is, if I add an empty Web API 2 controller, define these methods manually along with some other endpoints, I can either call the endpoint like the first call or the second call, but not both.
Is there a way to set up routing of an endpoint which would accept both options?
PS: I know how to separately set up routing for each of above options. My question is whether it is possible to set up for both.
Related
I'm working on a service fabric project with multiple stateless services. When i try to add versioning as in the code below
[Authorize]
[ApiVersion("2.0")]
[Route("api/v{version:apiVersion}/[controller]")]
public class SessionController : Controller
{
...
}
it's not working when calling the service later using Postman or using some client winforms app i made just to call this service. And when i say it's not working i mean it's not looking for a specific version i placed in the controller.
e.g.
I'm calling http://localhost:1234/api/v1.0/session/set-session and as you can see in my controller i only have version 2.0. Now my API gets hit this way or another no matter what version number i put in.
I added code to the Startup.cs
services.AddApiVersioning(options => {
options.DefaultApiVersion = new ApiVersion(2, 0);
options.AssumeDefaultVersionWhenUnspecified = true;
options.ReportApiVersions = true;
options.ApiVersionReader = new HeaderApiVersionReader("x-api-version");
});
Specific API call looks like this:
[HttpPost]
[Route("set-session")]
public async Task<IActionResult> SetSession([FromBody] SessionModel model)
{ ... }
Can anyone tell me what am i missing or maybe api versioning is not supported in service fabric at all?
Thanks.
Does your solution work locally? Based on what I see, I would suspect - no. This should have nothing to do with Service Fabric at all.
Issue 1
I see that your base class inherits from Controller, which is allowed, but is usually ControllerBase. No concern there, just FYI. The crux of the problem is likely that your controller has not applied the [ApiController] attribute. API Versioning defines IApiControllerSpecification and IApiControllerFilter, which is used to filter which controllers should be considered an API. This is important for developers building applications that have the UI and API parts mixed. A controller is a controller in ASP.NET Core and it was difficult to distinguish these two in the early days. There is now a built-in IApiControllerSpecification that considers any controller with [ApiController] applied to be an API. This can be changed, replaced, or completely disabled using ApiVersioningOptions.UseApiBehavior = false.
If your library/application is only APIs, you can decorate all controllers at once using:
[assembly: ApiController]
Since your controller is not currently being considered an API, all requests matching the route are being directed there. The value 1.0 is being considered an arbitrary string rather than an API version. This is why it matches at all instead of HTTP 400. I suspect you must only have one API and it is defined as 2.0; otherwise, I would expect an AmbiguousActionException.
Issue 2
Your example shows that you are trying to version by URL segment, but you've configured the options to only consider the header x-api-version. This option should be configured with one of the following:
URL Segment (only)
options.ApiVersionReader = new UrlSegmentApiVersionReader();
URL Segment and Header
// registration order is irrelevant
options.ApiVersionReader = ApiVersionReader.Combine(
new UrlSegmentApiVersionReader(),
new HeaderApiVersionReader("x-api-version"));
Default (Query String and URL Segment)
// NOTE: this is the configuration
// options.ApiVersionReader = ApiVersionReader.Combine(
// new QueryStringApiVersionReader(),
// new UrlSegmentApiVersionReader());
Side Note
As defined, using the URL segment and header versioning methodologies don't make sense. You have a single route which requires an API version. A client will always have to include the API version in every request so there is no point to also supporting a header.
If you define 2 routes, then it makes sense:
[Route("api/[controller]")] // match by header
[Route("api/v{version:apiVersion}/[controller]")] // match by url segment
Versioning by URL segment, while common, is the least RESTful. It violates the Uniform Interface constraint. This issue demonstrates yet another problem with that approach. Query string, header, media type, or any combination thereof will all work with the single route template of: [Route("api/[controller]")]
Observation 1
You have configured options.AssumeDefaultVersionWhenUnspecified = true. This will have no effect when versioning by URL segment. It is impossible to provide a default value of route parameter in the middle of a template. The same would be true for api/value/{id}/subvalues if {id} is not specified.
This option will have an effect if you:
Add a second route template that doesn't have the API version parameter
You update your versioning strategy to not use a URL segment
It should be noted that is a highly abused feature. It is meant to grandfather in existing services that didn't previously have explicit versioning because adding it will break existing clients. You should be cognizant of that if that isn't your use case.
So now that Angular 2 is in beta I have been using observables on the client side and I have been using ASP.NET Core Web API on the server side. My question is if I want to display a value on my website as that value changes I understand how to do it on the client side with Observables, but how do I use Observables with a Web API service on the server?
Thanks for your time....
If I understand your question correcly, you can use Refit , to generate the implementation of an interface that returns an IObservable from a REST API.
For the example below, an interface is declared for the /users/{user} REST API. The return type is an IObservable and when you compile this, Refit generates the implementation.
public interface IRestAPI
{
// Returns the raw response, as an IObservable that can be used with the
// Reactive Extensions
[Get("/users/{user}")]
IObservable<HttpResponseMessage> GetUser(string user);
}
To initialize it, you do something like this:
var api = RestService.For<IRestAPI>("http://api.example.com/users");
I want to convert our existing WCF REST web services to ASP.NET Web APIso I started to look into it.
Getting one of my function (i.e. login) up and running in ASP.NET Web API was quite straight forward but there is one thing I'm confused about and I hope one of you can clarify this for me.
In our WCF REST web service, our login (POST) function was called as follows:
http://localhost/mywebsite/mywebservice.svc/Authentication/Login
We'd pass a LoginRequest to it and we'd get a LoginResponse back.
Now in ASP.NET Web API, I've our Login (POST) function is being called as follows:
http://localhost/api/authentication and I'm passing the same LoginRequest and I get the same LoginResponse.
My confusion is, how does ASP.NET Web API know to use the Login function which is defined in the AuthenticationController?
I assume it has something to do with the parameter type being passed but what if I have another function that has the same parameter type, how would it differentiate between the 2?
For example, what if I had a LocalLogin and CloudLogin (not the case btw) and both require the LoginRequest as an input parameter and both return the LoginResponse, how would it know which one to call since it's not part of the URI?
Thanks.
I am using ASP.NET MVC 4 WEB API to create a Restful API service. This is my first go at it, so if you feel I am taking a wrong approach please feel free to correct.
I want to create a rest API (only & not a website, the consumer of the api can decide where they want to consume it), in the past I have used Restful WCF service to achieve this.
I have created a new ASP.NET MVC 4 Web Application and chose the WebAPI project template. I have added a controller class 'CatalogueController.cs' the purpose is on Get() operation I want to return the Catalogue list. The CatalogueDo contains only one property 'Service' of type string.
[System.Web.Http.HttpGet()]
public HttpResponseMessage Get()
{
return Request.CreateResponse(HttpStatusCode.OK, Catalogue);
}
When I run the application the browser loads with the URL http://localhost:5502/ resource not found, if I add the controller name http://localhost:5502/Catalogue/ the browser pops open a notepad with,
[{"Service":"Exchange"},{"Service":"Holidays"}]
The data is correct but
the browser keeps showing resource not found and after my request has been served the URL changes to http://localhost:5502/.
Question,
Am I doing something wrong? Should the response that pops up in the
notepad not be shown as xml in the browser it self?
Why does the controller name get removed from the URL once the request has been served?
Is it at all possible to invoke this REST service from Excel or Power Pivot?
I'm researching the new ASP.NET MVC4 Web API framework. I'm running Visual Studio 2011 beta on the Windows 8 consumer preview.
My problem is that none of the official samples for the new Web API framework use any kind of database backend. In the past, I've been able to create a local SQL CE database and serve it up via a WCF Data Service using Entity Framework as the ORM. How do I do the same with Web API?
Also, is this even a valid question? Should I just keep using a WCF Data Service if I want to expose an Entity Framework mapped SQL CE database? It seems to work fine, other than not offering the flexibility to choose response formatters that I might get with web api.
If you look at the official Contact Manager sample, you'll find that the Repository Pattern is used to access the data layer.
Also, bear in mind that in this particular example there's also DI via Ninject.
In my case I've easily plugged this onto an already existing EF model.
Here's an example for a repository implementation
///MODEL
public class SampleRepository : ISampleRepository
{
public IQueryable<Users> GetAll()
{
SampleContext db = new SampleContext();
return db.users;
}
[...]
}
///CONTROLLER
private readonly ISampleRepository repository;
public SampleController(ISampleRepository repository)
{
this.repository = repository;
}
//GET /data
public class SampleController : ApiController
{
public IEnumerable<DataDTO> Get()
{
var result = repository.GetAll();
if (result.Count > 0)
{
return result;
}
var response = new HttpResponseMessage(HttpStatusCode.NotFound);
response.Content = new StringContent("Unable to find any result to match your query");
throw new HttpResponseException(response);
}
}
Your mileage may vary though, and you might want to abstract out some of this data access even further.
Good news is that plenty of patterns and ideas that you may have already used on MVC-based projects are still valid.
I haven't worked with WCF Web API, so I can say for sure if you can use it same way as you did with WCF Web API, but I'm sure you can use EF with ASP.NET Web API. I suggest you take a look at how ASP.NET MVC makes use of EF, it should be very similar how you would use it with ASP.NET Web API.
As for other question, if you're planning some new development you should consider using ASP.NET Web API since there's an announcement on wcf.codeplex.com saying:
WCF Web API is now ASP.NET Web API! ASP.NET Web API released with
ASP.NET MVC 4 Beta. The WCF Web API and WCF Support for jQuery content
on this site will be removed by the end of 2012.