i followed this to learn how ODataController works, everything is OK but when i changed the request uri
from
"localhost:49292/odata/Employees" //result: 200
to
"localhost:49292/odata/employees" //result: 404
to say one word: "odata" or "Odata" and "Employee" are all ok, but lowercase "employee" return 404. any explanation about this. Moreover, the routes in asp.net mvc is not case-sensitive afaik.
how about including a Route attribute and direct it to lower case. for Upper case web api will take care about it
[Route("odata/employees")]
add this on the top of the controller
if odata is common for every action then you can include [RoutePrefix] attribute
You can manually do it using the ODataModelBuilder instead of the ODataConventionModelBuilder
e.g
var builder = new ODataModelBuilder();
builder.EntitySet<Order>("Employees");
builder.EntitySet<Order>("employees");
this will work but your metadata will show 2 entity sets:
{
#odata.context: "http://localhost:62881/$metadata",
value: [
{
name: "Employees",
kind: "EntitySet",
url: "Employees"
},
{
name: "employees",
kind: "EntitySet",
url: "employees"
}
]
}
lowercase "employee" return 404.
I hope you probably didn't have the typo like that.
AFAIK, there is a case limitation on filter and properties. (You can vote there https://aspnetwebstack.codeplex.com/workitem/366 ) but not sure about the controller name..
You can create the REST server using web api without having oData as well..
Related
I would like to implement a simple URL shortener feature like Bitly.
My Controller name: WebController
My Action name: Redirect
As the name suggests the action redirects the user from the short URL to the full URL.
To call this action I need: https://myappdomain.com/web/redirect?id=3422
But I would like to be able to call this feature in a much shorter way with a different (shorter) domain and without the need to call the action name: https://shorterdomain.com/3422
Can you guide me how can I do this? I am a bit lost even for what to search for:(
Add a route to the shorter URL so MVC knows what controller and action will handle the request. Something like this:
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(name: "redirection",
pattern: "{id:int}",
defaults: new { controller = "web", action = "redirect" });
... your existing routes
});
I have ASP.NET Web Api 2 application which already has controllers. Now, we have new controllers that need to be added but with prefix (v10)
/api/products/1 // Old controller
/api/v1/proucts/1 // the new controller
I tried to version the API with ApiVersion attribute:
[ControllerName("Products")]
[ApiVersion("1.0")]
[RoutePrefix("api/v10/[controller]")]
public class ProductsV1Controller : ApiController
{
...
}
And the old controller is:
public class ProductsController : ApiController
{
...
}
The routing without the version is still working and accessing the old controller, but when I call this routing:
api/v10/products/1
It returns 404 Page not found. The same get method is written in both controllers just for testing purposes.
In my Startup config:
httpConfig.MapHttpAttributeRoutes();
httpConfig.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional },
constraints: null);
does anyone know how to configure the routing to navigate correctly?
#Sajid was mostly correct. When you version by URL segment, you need to use the API version route constraint. There's a couple of issues at play. It looks like you are migrating from an unversioned API to a versioned API, which is a supported scenario. The example values you gave are incongruent. It looks like you are going from v1 to v10. The values are irrelevant, but realize that your existing API does have some logical name, even if you never previously assigned it a value.
Issue 1
You didn't specify your setup, but it should be something like:
var constraintResolver = new DefaultInlineConstraintResolver()
{
ConstraintMap = { ["apiVersion"] = typeof( ApiVersionRouteConstraint ) }
};
configuration.MapHttpAttributeRoutes( constraintResolver );
configuration.AddApiVersioning(
options =>
{
// required because the original API doesn't have a version in the URL
options.AssumeDefaultVersionWhenUnspecified = true;
// this is already the default value, but you might need to change it.
// this is the value that will be 'assumed' by the original, unversioned
// API. it is addressable by /api/products. if you meant to start at 1.0,
// then you can use a lower value such as 0.9
options.DefaultApiVersion = new ApiVersion(1, 0);
});
Issue 2
The token [controller] is not supported in Web API. This is a concept, along with [action], were introduced in ASP.NET Core routing.
You didn't fully elaborate on how you solved the issue, but your changes almost certainly highlight how mixing styles can be confusing. It's unclear if the API was matched by an attribute route or a convention-based route.
Issue 3
Your route template does not include the API Version route constraint (see Issue 1 for registration). This is required so API Versioning knows how to extract the API Version from the URL. API Versioning does not do magic string parsing with regular expressions, etc.
The template should be: [RoutePrefix("api/v{version:apiVersion}/products")] as mentioned by #Sajid. Keep in might that the literal v is not part of an API Version, but is common in the URL segment versioning method. version is the name of the route parameter, but can be any value you want. apiVersion is the key of the registered route constraint, but you can change it in the template if you also change it in the registration (see Issue 1).
Issue 4
The annotated API version is 1.0, but the route template seems to imply that you meant 10.0. You can use any value you want, but they need to be congruent. If you do mean to use 1.0 don't forget to the change the options.DefaultApiVersion or you'll get a runtime exception because the original API and your new API will be considered duplicates as they have the same API version. There is no concept of no API Version once you opt in.
For example:
// ~/api/v10/products
[ApiVersion("10.0")]
[RoutePrefix("api/v{version:apiVersion}/products")]
public class ProductsV1Controller : ApiController { }
Issue 5
I strongly advise against mixing routing styles. It is supported, but it can be confusing to troubleshoot and for maintainers. I would choose either Direct Routing (aka Attribute Routing) or Convention-Based Routing. There are edge cases where mixing them will not work, but they are rare.
This means you should choose one of the following:
Attribute Routing
// setup (see Issue 1)
configuration.MapHttpAttributeRoutes( constraintResolver );
// old controller
[RoutePrefix("api/products")]
public class ProductsController : ApiController { }
// new controller; ControllerNameAttribute isn't need because it's not used
[ApiVersion("10.0")]
[RoutePrefix("api/v{version:apiVersion}/products")]
public class ProductsV1Controller : ApiController { }
Convention-Based Routing
// setup
httpConfig.Routes.MapHttpRoute(
name: "VersionedApi",
routeTemplate: "api/v{apiVersion}/{controller}/{id}",
defaults: new { id = RouteParameter.Optional },
constraints: new { apiVersion = new ApiVersionRouteConstraint() });
httpConfig.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional },
constraints: null);
// old controller
public class ProductsController : ApiController { }
// new controller
[ApiVersion("10.0")]
[ControllerName("Products")] // required because the convention-based name is "ProductsV1"
public class ProductsV1Controller : ApiController { }
Warning: You can mix these styles, but troubleshooting will become more difficult. You need extensive test coverage to ensure things are correct. One-off manual testing may yield false positives.
I hope that helps
In our RouteConfig.cs file we have the following default route:
routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Original", action = "Index", id = UrlParameter.Optional },
namespaces: new[] { "Path.To.Controllers" }
);
Our application is split into several different "Areas". This particular route works perfectly fine.
We were asked to change one of our URLs, however the underlying codebase is the same. In an effort to avoid breaking existing links out there I'd like to setup my controller to support two different routes:
Here's an example of what the original URL looks like:
website.com/MyArea/Original
With the aforementioned "Default" route in place, this will be directed to the OriginalController in the MyArea Area, and will hit the default Index action since none was specified.
My goal is to setup another URL that will also direct itself to the OriginalController. That is,
website.com/MyArea/Other
Should route to the OriginalController in the MyArea Area, and hit the default Index action.
I've added the following to the RouteConfig.cs file:
routes.MapRoute(
name: "Other",
url: "Other/{action}/{id}",
defaults: new { controller = "Original", action = "Index", id = UrlParameter.Optional },
namespaces: new[] { "Path.To.Controllers" }
);
What I'm finding is that the Default route config is always used in favor of the Other route config, which causes a binding issue stating "OtherController could not be found". I suspect this is because they have a very similar signature in the url template, but I'm not entirely sure how to get around that.
I'm aware that there's a Route attribute also, which I'm not opposed to using. I unfortunately was unsuccessful in getting that setup correctly though.
After researching and attempting several different combinations I still can't get both URLs to route to one controller.
What am I doing wrong?
I was able to get the expected result using RouteAttribute on the controller itself (thank you #Michael for the resources and making me take another look at the RouteAttribute), rather than conventional MapConfig routing. As I described in my question above, I was having difficulties when attempting the Route approach in that I was receiving 404 errors stating the "resource could not be found".
It turns out the above errors were due to the fact that my attribute routing wasn't being wired up in the correct order, which forced the conventional route to be used (e.g. Default MapConfig) over my Route attributes.
I stumbled upon this SO post which states:
You are probably combining convention based routing with attribute
routing, and you should register your areas after you map the
attribute routes.
The line
AreaRegistration.RegisterAllAreas(); should be called AFTER this line:
routes.MapMvcAttributeRoutes();
When working with Areas, you must register those areas after you register the attribute routing. I was originally registering my areas in the Application_Start method of Globas.asax.cs, which is called before the RouteConfig.RegisterRoutes. I moved this registration to right below my MapMvcAttributeRoutes call in the RouteConfig.cs file, which allowed the following route attribute on the controller to work as expected:
[RouteArea("MyArea")]
[Route("Original/{action=index}", Order = 1)]
[Route("Other/{action=index}", Order = 0)]
public class OriginalController : Controller {
...
...
public async Task<ActionResult> Index() { ... }
}
With the above in place, I can now navigate to either of the below URLs which will properly route to the "Index" action of my OriginalController:
website.com/MyArea/Original
website.com/MyArea/Other
This works. However, I do have another action defined that choked up the attribute routing and caused the conventional Default route (defined via the MapConfig function) to be used. My action signature:
public async Task<ActionResult> Details(int id) {
...
}
The route to this action is: website.com/MyArea/Original/Details/123, which also satisfies the default conventional route of {area}/{controller}/{action}/{id}.
The way around this was to go a step further with defining route attributes at the action level:
[Route("Original/Details/{id:int}")]
[Route("Other/Details/{id:int}")]
public async Task<ActionResult> Details(int id) {
...
}
Now my Route Attributes are found first, then the conventional route is used.
I have a controller in my Rest API that expects an array of json (in POST)
{
data: [
{
name: "marc"
},
{
name: "john"
}
]
}
Submitted data are then saved in database.
I don't know what annotation to use in order to tell "nelmio api doc bundle" to generate the appropriate html page in order to have capability to test my API by creating multiple items (an array of items).
To resume the question is : Can nelmio documentation generates a dynamic collection of forms ?
You can test your API through nelmio sandbox.
Nelmio have the "New Parameter" button which is can add multiple key => value parameters.
I'm developing an app with Spring MVC and the view in extjs 4. At this point, i have to create a Grid which shows a list of users.
In my Spring MVC controller i have a Get method which returns the list of users in a jsonformat with "items" as a root.
#RequestMapping(method=RequestMethod.GET, value="/getUsers")
public #ResponseBody Users getUsersInJSON(){
Users users = new Users();
users.setItems(userService.getUsers());
return users;
}
If i try to access it with the browser i can see the jsondata correctly.
{"items":[{"username":"name1",".....
But my problem is relative to request of the Ext.data.Store
My Script is the following:
Ext.onReady(function(){
Ext.define('UsersList', {
extend: 'Ext.data.Model',
fields: [
{name:'username', type:'string'},
{name:'firstname', type:'string'}
]
});
var store = Ext.create('Ext.data.Store', {
storeId: 'users',
model: 'UsersList',
autoLoad: 'true',
proxy: {
type: 'ajax',
url : 'http://localhost:8080/MyApp/getUsers.html',
reader: {type: 'json', root: 'items'}
}
});
Ext.create('Ext.grid.Panel',{
store :store,
id : 'user',
title: 'Users',
columns : [
{header : 'Username', dataIndex : 'username'},
{header : 'Firstname', dataIndex: 'firstname'}
],
height :300,
width: 400,
renderTo:'center'
});
});
When the store tries to retrieve the data and launchs the http request, in my firebug console appears OPTIONS getUsers.html while the request in the browser launchs GET getUsers.html
As a result, Ext.data.Store has not elements and the grid appears with the columnames but without data. Maybe i've missed something
Thank you
You can change the HTTP methods that are used by the proxy for the different CRUD operations using actionMethods.
But, as you can see in the doc (and as should obviously be the case), GET is the default for read operations. So the OPTIONS request you are observing is quite puzzling. Are you sure that there's not another part of your code that overrides the default application-wide? Maybe do a search for 'OPTIONS' in all your project's JS files, to try and find a possible suspect. Apparently there's no match in the whole Ext code, so that probably doesn't come from the framework.
Edit:
Ok, I think I've got it. If your page is not accessed from the same domain (i.e. localhost:8080, the port is taken into account), the XHR object seems to resort to an OPTIONS request.
So, to fix your problem, either omit the domain name completely, using:
url: '/MyApp/getUsers.html'
Or double check that your using the same domain and port to access the page and make the requests.