Develop Reference

Using POST or GET for a WebAPI Action method that returns a list, but requires params

Currently I have the following standard functions in each of my controllers to handle basic CRUD operations:
GET /api/todo Get all to-do items
GET /api/todo/{id} Get an item by ID
POST /api/todo Add a new item
PUT /api/todo/{id} Update an existing item
DELETE /api/todo/{id} Delete an item
However, the time came where I realized I actually need to pass multiple parameters to get a list of todo items that is filtered at the database level rather than retrieving all of the items and using linq.
For example here is how I decided to go about it:
In my Controller:
// POST: api/todo
[HttpPost]
public IList<TodoItem> Get([FromBody]GetTodoItemsRequest request)
{
return _todoItemManager.GetTodoItems(request.Name, request.CategoryId);
}
As you can see I created a new Model called GetTodoItemsRequest which will have a property for each of my parameters. In this case: Name, CategoryId.
I figured when dealing with multiple parameters and retrieving a list it is best to do POST and create a model specifically for it. Rather than using a GET and passing all kinds of information in the url.
It seems a bit strange to be doing the above... Would msot see it as a perfectly fine solution or is there something I am missing in the WebAPI world?

I believe that is semantically incorrect to use POST method for a simple read operation, even if you need a complex model. You are doing a pure query on your resource called todo, and this should really be a GET operation for many reasons:
It should be cachable: POST request aren't cachable by their nature, and caching is an important constraint in RESTful services.
It should semantically indicate that no side-effect will be raised from the call: GET requests must be idempotent and safe, POST operations, instead, indicate some kind of data manipulation. Your operation (filtering) is both idempotent and safe, so it should be spontaneously represented by a GET request.
The part of the URI after a ? character is called query string for a reason: it represent parameters that further specify the scope of a request. Well, isn't filtering results just an example of this approach?
Apart from that, it seems to me that, if Name and CategoryId are required parameters for your query, your filtering operation could be better represented by another URI in which Name and CategoryId are turned into route parameters:
http://yourhost.com/api/users/{name}/categories/{categoryId}/todos
Assuming a relationship between your name parameter (a user name maybe?) and the categories.
If, instead, your parameters are completely optional, then leaving them as query string parameters is the best choice:
http://yourhost.com/api/todos?name=nameValue&categoryId=categoryIdValue
A side note:
you should really use plural for your resources if they represents a collection of items: e.g. api/todo will return an array of todos, so you should rename it into api/todos.

.NET OData Web api

I have 2 ways to use a model generated by Entity Framework. I can not find which to use when and why.
Method 1
ODataQueryOptions<Key_Result> options (Passed as function argument)
private ODataQuerySettings settings = new ODataQuerySettings();
IQueryable<Key_Result> result;
try
{
result = options.ApplyTo(DataAccessFunction.Key(keyIds), settings) as IQueryable<Key_Result>;
}
Method 2
IQueryable<Log> result;
try
{
result = AccessModel.Log;
}
So far, I have used them in my code without knowing what is correct or why both are even used. I can't find any material to help me too.
Also, the first one I am using in Odata endpoints created using the table valued functions in sql while the second one I am using with endpoints created using simple tables and views.
But if Entity framework is consistent, it shouldn't matter. And I should be able to use the two approaches interchangeably. Can they be used interchangeably, what is the difference which makes them preferred for one situation (Table valued function) and not preferred for the other one (Tables, views).

Both can be used but both have different uses. If my settings parameters such as null propagation, stable sort or page size have to be set I could use method 1.
However, setting page size etc. could also be done without this. Method 2 is the simplest but does not handle any page sizing or null propagation etc.

Is it possible to get a list of all values that can be returned in a web service

Is it possible to get a list of all values that can be returned in a web service?
I am looking at APIs from Open Weather Map doing these 2 calls:
http://api.openweathermap.org/data/2.5/weather?q=paarl
http://api.openweathermap.org/data/2.5/weather?q=London,uk
If you look at the JSON returned you will see that for Paarl there are extra properties in main like grnd_level and sea_level that London doesn't return.
Is it possitbly for me to see all that values that can be returned and not just the values that are returned. Maybe I search for another region and then it returns other values that I am not aware of. I can't always go and check the JSON results.
I would like to cater for most/almost all scenarios.

API does not provide exact props, so it might be different for cities and be based on station too. As for me, you should choose properties you wanna see in your program and display them, no need to show all the possible data.

Server side paging with MVCContrib grid

I have to use stored procedures to fetch and page data. This particular stored procedure has all sorts of parameters, including paging information. Obviously, paging needs to be done server side, one page of data needs to be fetched each time a user selects a new page.
I'm trying to get this work with MVCContrib, but it seems to me that the grid and its pager support only local paging and filtering. Number of available pages is determined by the number of already present items in the collection, or so it seems to me.
Is there a way to make MVCContrib work with server side paging?

There is a class called CustomPagination in MVCContrib. The constructor takes following arguments
(Enumerable<T> dataSource, int pageNumber, int pageSize, int totalItems)
Then you pass that to the Grid and Pager.

You'll need to implement the IPagination interface yourself, add a page parameter to your action method then pass this into your stored procedure to get the appropriate collection of items. Then populate each of the IPagination properties from this and your knowledge of how your stored procedure works.
If you want more concrete examples of this, a sample of your stored procedure (or cut down version of it) may be helpful.
"Number of available pages is determined by the number of already
present items in the collection, or so it seems to me."
Perhaps you're looking at samples that are using a flavour of LINQ. This does not necessarily mean that the entire collection is in memory. Also, even if they are in memory, I would still call this server side paging - To me, client side paging in a web application means javascript.
PS: this may help you get started, though by the sounds of it you will need to ignore the Entity Framework bits of it:
http://weblogs.asp.net/rajbk/archive/2010/05/08/asp-net-mvc-paging-sorting-filtering-using-the-mvccontrib-grid-and-pager.aspx
Where they use the "AsPagination()" extension you'll need to call your stored procedure and populate your own implementation of IPagination.

URL Querystring - Find, replace, add, update values?

We inherited some C# code as part of a project from another company which does URL redirects that modifies the existing query string, changing values of items, adding new params, etc as needed. The issue however is that the code is buggy at best, and ends up duplicating items in the query string instead of updating them properly. The code works on the first pass but on additional calls the duplication issues become apparent.
Ex: MyPage.aspx?startdate=08/22/09&startdate=09/22/09
Instead of duplicating the item it needs to be either updated with the new value if it already exists, or added if not there already.
Is there a C# class or set of functions for handling query strings, allowing a simple means to access and update/add parameters that gets around these issues instead of the blind add approach that seems to be in use now with the code? This needs to be able to handle multiple parameters that may or may not exists at all times and be added and updated on subsequent calls.
We would sooner use existing logic than recreate something if possible so as to get this resolved quickly in a semi standard way for future maintainability and reuse.

Yes I would suggest converting the querystring to a collection by using HttpUtility.ParseQueryString()
You can then find/add/update/replace values directly in the collection, before re-creating the querystring from this collection.
This should make it easier to spot duplicates.

You can access and manipulate all values of your Querystring through the Request.QueryString collection. Here's a link.

this seems a basic design problem.
instead of updating the current query string, what SHOULD be done is simply adding all the parameters to the base at every time.
sure, you CAN update it, but (pseudocode)
if querystring exists
then update query string
else
add query string
will get crazy when you start using more than 1 variable.
redesign would be best, effort allowing.

The WCF REST Starter Kit available on ASP.NET also include a new "HttpQueryString" helper class that will most likely be included in the .NET 4.0 time frame into the base class library.
See an excellent screencast on how to use this utility class here:
http://channel9.msdn.com/shows/Endpoint/endpointtv-Screencast-HttpClient-Query-String-and-Form-Input-Management/
Marc