Develop Reference

Updating blog resource by ID

I'm creating an API which would allow users to create, update and delete blog posts. I've got to the point where I want to now create an update handler for the blog post but creating a model for this call got me thinking..
For a PUT request should the id of the blog being updated be within the URI or be within the body like so:
In the URI:
/api/blog/23
In the body:
{
"id": "23",
"title": "new blog title"
}
Is there a right and wrong? If not, then what is generally the most followed convention for RESTful api's?

Technically there is no right or wrong way to design an API. However, a well designed API will be much easier to understand.
Assuming this is a REST API, my preference is to stay consistent. If your API requires an ID within the URI to GET resources then keeping things consistent with an ID in the URI to PUT would be my recommendation.
Microsoft has a good API design guidance article which also recommends to keep URIs consistent.

PUT, in HTTP, means something very specific
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.
It's a request that asks the server to change the servers copy to match the representation provided by the client. Think "Save", or "Overwrite" -- a content management action.
So if the JSON representation of this blog post should be an id, a title, and nothing else -- then that would be fine.
If you intention is to change the title, while leaving the rest of the representation unchanged, then you either need to (a) send the entire representation, including your edit or (b) choose a method with different semantics (POST or PATCH could make sense).
The URI is an identifier -- think key in a hashtable/dictionary. There's no particular reason that data encoded into the identifier needs to match data in the representation. It certainly can -- we'll often encode into the URI information that the server will use in its own internal implementation -- but /4ca7fce6-efce-42d1-8fc6-666c3cae4f90 is a perfectly valid identifier for a resource.

Add rel="nofollow" automatically to all outbound links in ASP.NET

Any geniuses on StackOverflow ever made a solution which automatically adds rel="nofollow", to all external links?
I'd just like to apologise, I'm very new to backend coding - my attempts have literally got nowhere hence why I haven't posted them.
I've found some solutions in php, but nothing in ASP.NET.
I have a solution in jQuery, but the issue is - it'll be added after load. This is no good for telling Googlebot to ignore said links on my pages.
The jQuery solution is:
$("div.content a[href^='http']:not([href*='mysite.co.uk'])").attr("rel",
"follow");

One way would be to create your own custom HttpModule that set's the response to use a derived stream class to filter the HTTP body. There is a linked example in there on how to create a basic HttpModule. Github or Nuget may have a filter class that someone has written to do modifications the output stream when it's content type is text/html that you might be able to modify for your needs.
To build one on your own you will essentially need to attach to the BeginRequest event and set a filter to the HttpApplication's response.filter. That filter will be in charge of implementation of reading the response the page/control/ihttphandler has created and modifying it before it sends it to the client and then implementing the write to the client.

updatepanel vs page methods

I use update panels all the time when i wanna to update specific part of my page but recently i face performance problems ( i mean it 's slow in rendering the intended control and sometimes it doesn't work and need multiple click to work !!
so my question is :
Is the page method could be considered as an efficient alternative to
the update panel and do the ajax magic ?
What are the other alternatives?
please if possible a simple example to clarify how to replace the update panel using with page methods ?

I used to be like you some years ago, I used to use UpdatePanel to gain performance, to have the wrong idea I was increasing the performance of my applications...
Well I was totally wrong, UpdatePanel is the root of all UI-evil, first of all it hides the complexity of using AJAX which makes it easy for most of us, giving us the wrong idea that we are creating responsive applications, which is worst than if we weren't using it at all (that's the main reason I used to use it in all my pages, and I am sure that's the reason why many developers use it... 'cos it's easy).
Consider the following articles:
Why you should not place your whole site in an UpdatePanel
UpdatePanel is evil
When you understand what the UpdatePanel really does against a simple call to a PageMethod or a REST WCF Service, you will see the huge difference between them.
UpdatePanel. When you perform a post from an UpdatePanel, the whole page life-cycle has to be executed, this means, it requires to send all the page ViewState on each post, when your page grows in complexity with several controls, the ViewState will certainly be huge and this will certainly be a performance issue. Using them you only gain partial rendering, the controls inside your UpdatePanel will be rendered without a full post back although you need to send the whole ViewState on each request.
PageMethod. Page methods are static, they are called like if they were a service method, they do not need to create the whole page life-cycle in order to be executed, therefore, they execute faster.
So it would seem that using PageMethods would be the solution, the problem is that PageMethods are usually used to return JSON objects which means, that you will have to render these objects manually. This means that if you want to get rid-off all your UpdatePanel you will have to change the controls used in your views, you won't be able to use the GridView out-of-the-box for example, instead you would have to change it for the JQGrid (or similars).
This is natural if you are creating a MVC application, but with traditional ASP.Net this is not straightforward.
You also need to consider something very important, the ViewState is validated by default on each post, you can turn it off, but it is not recommended if you want to be sure your ViewState has not been corrupted (take a look at this question).
Consider this example, you have two DropDownList controls, (named: ddl1, ddl2) ddl2 depends on ddl1 so using the SelectedIndexChanged event you fill the second drop down list. But if you attempt to do the same using AJAX calls (without an UpdatePanel), you will face two problems
Rendering, you need to manually add objects to the HTML select control representing the DropDownList. You could use a third party framework to bind these controls using javascript, I can recommend you knockoutjs (it's awesome)
This is the problem. After you have changed the content of the second DropDownList using javascript, you cannot do a simple post to your page because the ViewState will not be valid, and you will see the following exception:
Invalid postback or callback argument.
The workaround is to specify which values will be valid in the server side, in order to do that you need to override the page Render method and specify each one of the values of the second drop down list, but this will increase the page size and obviously, this is not a good option
Take a look:
ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part I
ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part II
So as a summary, if you want to get rid-off all your UpdatePanel controls, you will need to replace the existing server controls for javascript-friendly controls. Also remmeber that if you do that, instead of relying on the page post mechanism, you would have to use AJAX to perform operations on the server, otherwise, you will get the Invalid postback or callback argument. exception. In other words it would be better to consider moving to a MVC application if possible.

There is an alternative to UpdatePanels, but still using PageMethods. It is a combination between jQuery and jQuery templates. It is proven to be faster than the UpdatePanels. Further reading on the resource below, where you can find more articles dedicated to this topic.
http://encosia.com/use-jquery-and-aspnet-ajax-to-build-a-client-side-repeater/

You might read about the coming WebAPI in .NET 4.5. It's for WebForms as well as MVC and may be a viable solution to your problem if you can wait on 4.5.
Just use it in combination with any jQuery template engine.
http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx

Have a look at http://uframe.codeplex.com/

Is Request.QueryString without ? or & possible?

Is it possible to get the QueryString value without using ? or & in the url?
I would like to have it like this:
http://www.colors.com/Red
string id = Request.QueryString["?"];
Instead of following:
http://www.colors.com/?ColorID=Red
string id = Request.QueryString["ColorID"];

No. a query string is defined by the appearance of a ?.
The example you give would redirect the user to a directory.

If you want to still be able to access the value of color-id through Querystring, then you should look at Rewriting. This can be due to legacy code that you can't change or other forms of interacting with 3rd party code. The benefit or Rewriting is that the code that ends up being executed doesn't know how the url looked like before it was rewritten and it can keep working as if there were a Querystring parameter named ColorID.
In its simplest form you need to call the Rewrite method of HttpContext, which will spin up a new request internally that executes code that matches that url without the user noticing anything. One caveat of this can be, that your legacy code doesn't know how to render correct links in menus and stuff, so you would keep having urls like ?ColorID=Red where it should have been just Red.
In IIS 7 and up, there is a built in filter where you can write your rules and patterns so you don't need to write your own code that matches incoming requests and calls HttpContext.Rewrite. Read more about it here on MSDN.
Now, Routing is a whole other thing. Its a Asp.net feature and doesn't work on top of existing legacy code but needs to be used with it. Meaning that the executing code needs to know that the request was routed to it. This of course has many benefits and of you're writing a new system then i would definitively recommend using Routing over Rewriting. There is a good article here about the differences and some SO questions also cover the topic:
IIS URL Rewriting vs URL Routing
Url Rewriting vs. Routing

It sounds like you may want to implement an MVC website.
Take a look at this MSDN documentation for more information.

How do I allow the GET request for only one method or webservice?

As I've found here, I can change the webconfig to allow/disallow methods on webservices.
I need only one method to be a GET and for the others it should be a POST, is there a way to configure just one method (or maybe webservice if there is no other way) to accept GET requests? I am on IIS7.

You can do it by changing the handler mappings, either in IIS or through the httpHandler mappings defined in the web.config.
Or you can have an HttpModule do it.
However, since you are already using asp.net (to judge from your tags) and you've only one exception, then an easier way is probably just to do it at that level. If not, the logic is much the same for doing this from an HttpModule.
In your page-base class (if you don't already define an abstract class in between System.Web.UI.Control.Page and your own pages it might be worth looking at, it's a handy place to put commonly used methods) put a virtual member that gets called before the main page-load handler (e.g have a method called OnLoad that calls this and then your "real" page-load method).
In this method, check the http method used, and if it's not correct set the status code to 405, output an error page for bonus marks, and then stop all processing.
In your page that allows get, override and change the method you check for.
If your class structure doesn't allow this to be done easily, then the HttpModule approach will be easier. Here you'll have to examine the URI to know which method to allow, but the rest is pretty much the same.

Depends on the web server.
You can return errors on certain requests in Apache, for instance.
Use the Limit directive:
<Directory />
Options All
AllowOverride All
<Limit POST PUT DELETE CONNECT PROPFIND PROPPATCH>
# Require valid-user
Deny from all
</Limit>
</Directory>
Edit - Just found the documentation on this: http://httpd.apache.org/docs/2.0/mod/core.html#limit