Is there any guidance/recommendations on how to handle additional GET methods and different critria? This isn't GET specific, but is applicable to any situation where you have multiple methods handling the same HTTP verb.
In my situtation, I'm building an internal web service using Web API. Primarily an ASP.NET MVC site will talk to the web service, but there will be a WPF component and potentially some AJAX that will talk to the service directly.
The problem I'm having is that in designing the API, not everything is straight CRUD. In addition to the generic CRUD methods I'm going to have methods that do specific things like:
Get Customers By Company ID
Get Customers By Last Name Pattern Match (Search)
Get Customers By <Insert Criteria Here>
For the more specific functionality I started putting these methods into more specific controllers, so instead of putting them in the CustomerController, I put them in a MarketingController, but I'm still running into the same problem.
Any ideas or suggestions? I'm assuming that other languages/frameworks may have guidance on this subject, so I wouldn't mind looking at some Ruby/Python/Whatever code to understand concepts, if you boys/girls know of some.
OK for some reason I missed the part where you can simply define your own routes. I think that solves my problem, but I'd still be interested to see what other think on the subject, since this must be pretty common.
This looks more like "search for customers by" than "get customers by". I would urge you to use a query string for these. Is there a reason you want these in your URI path?
For the first one, you might also consider just returning the customers on a Company resource, e.g. CustomerController. You'd probably want more than just the list of customers anyway, but you could at least have a meaningful, defined URI for companies with
extra info about the company, etc.
Also, instead of using Web API, have you considered using
Solr? That seems like it might be a better fit for this sort of thing. We use this and
SolrNet on several sites, and it works beautifully. Solr enables you to create
facets and allow keyword filters in your searches.
Another quick thought: Would it make sense to include the "action" route in the tutorial inside the Web API project template so this type
of functionality is automatically available? Is there a downside to having both of these routes in there?
Here are both routes:
routes.MapHttpRoute(
name: "ActionApi",
routeTemplate: "api/{controller}/{action}/{id}",
defaults: new { id = RouteParameter.Optional }
);
routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
The "{action}" parameter isn't typically necessary for Web API controllers. Controllers in Web API are intended to represent HTTP resources, which should generally respond to GET, PUT, etc. in a standard way. You can certainly route around this design, but
that is why you don't see the additional parameter in the route.
I think the main reason I'm trying to do it this way so so I can keep both a base class implementation of the code that handles all of the HTTP communication. For example,
I threw together this tutorial with a simplfied version of the code I'm using to consume the service. I have a base class with implementations for the CRUD methods. I am trying to take it one step further and support additional methods.
I'm thinking about creating another base class method that looks something like this:
public IEnumerable<T> Get<T>(string action, int id, int top = 0, int skip = 0)
That doesn't handle all cases, but it should help minimize some duplication.
Interesting. Well, my first thoughts are that I wouldn't do it that way, but that doesn't mean it's wrong. :)
I would suggest you keep your client very light and flexible rather than trying to build one client to rule them all. If you want better guidance on building a good client, see http://restagent.codeplex.com/, though that may not be what you want.
skippyfire
Member
34 Points
31 Posts
Recommendations on additional GET methods?
Mar 28, 2012 02:08 PM|LINK
Is there any guidance/recommendations on how to handle additional GET methods and different critria? This isn't GET specific, but is applicable to any situation where you have multiple methods handling the same HTTP verb.
In my situtation, I'm building an internal web service using Web API. Primarily an ASP.NET MVC site will talk to the web service, but there will be a WPF component and potentially some AJAX that will talk to the service directly.
The problem I'm having is that in designing the API, not everything is straight CRUD. In addition to the generic CRUD methods I'm going to have methods that do specific things like:
For the more specific functionality I started putting these methods into more specific controllers, so instead of putting them in the CustomerController, I put them in a MarketingController, but I'm still running into the same problem.
Any ideas or suggestions? I'm assuming that other languages/frameworks may have guidance on this subject, so I wouldn't mind looking at some Ruby/Python/Whatever code to understand concepts, if you boys/girls know of some.
aspnetmvc csharp
skippyfire
Member
34 Points
31 Posts
Re: Recommendations on additional GET methods?
Mar 28, 2012 02:10 PM|LINK
OK for some reason I missed the part where you can simply define your own routes. I think that solves my problem, but I'd still be interested to see what other think on the subject, since this must be pretty common.
aspnetmvc csharp
panesofglass
Participant
758 Points
242 Posts
Re: Recommendations on additional GET methods?
Mar 28, 2012 02:18 PM|LINK
This looks more like "search for customers by" than "get customers by". I would urge you to use a query string for these. Is there a reason you want these in your URI path?
For the first one, you might also consider just returning the customers on a Company resource, e.g. CustomerController. You'd probably want more than just the list of customers anyway, but you could at least have a meaningful, defined URI for companies with extra info about the company, etc.
Also, instead of using Web API, have you considered using Solr? That seems like it might be a better fit for this sort of thing. We use this and SolrNet on several sites, and it works beautifully. Solr enables you to create facets and allow keyword filters in your searches.
skippyfire
Member
34 Points
31 Posts
Re: Recommendations on additional GET methods?
Mar 28, 2012 02:18 PM|LINK
Another quick thought: Would it make sense to include the "action" route in the tutorial inside the Web API project template so this type of functionality is automatically available? Is there a downside to having both of these routes in there?
Here are both routes:
routes.MapHttpRoute( name: "ActionApi", routeTemplate: "api/{controller}/{action}/{id}", defaults: new { id = RouteParameter.Optional } ); routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } );aspnetmvc csharp
panesofglass
Participant
758 Points
242 Posts
Re: Recommendations on additional GET methods?
Mar 28, 2012 02:23 PM|LINK
The "{action}" parameter isn't typically necessary for Web API controllers. Controllers in Web API are intended to represent HTTP resources, which should generally respond to GET, PUT, etc. in a standard way. You can certainly route around this design, but that is why you don't see the additional parameter in the route.
aspnetmvc csharp
skippyfire
Member
34 Points
31 Posts
Re: Recommendations on additional GET methods?
Mar 28, 2012 02:30 PM|LINK
Hi panesofglass, thanks for your comments.
I think the main reason I'm trying to do it this way so so I can keep both a base class implementation of the code that handles all of the HTTP communication. For example, I threw together this tutorial with a simplfied version of the code I'm using to consume the service. I have a base class with implementations for the CRUD methods. I am trying to take it one step further and support additional methods.
I'm thinking about creating another base class method that looks something like this:
That doesn't handle all cases, but it should help minimize some duplication.
Thoughts?
panesofglass
Participant
758 Points
242 Posts
Re: Recommendations on additional GET methods?
Mar 28, 2012 02:54 PM|LINK
Interesting. Well, my first thoughts are that I wouldn't do it that way, but that doesn't mean it's wrong. :)
I would suggest you keep your client very light and flexible rather than trying to build one client to rule them all. If you want better guidance on building a good client, see http://restagent.codeplex.com/, though that may not be what you want.