Question

I was thinking ,

The WebApi along with routing mechanism works in such way that it reads the http verb ( GET POST etc…) and then searches for matched method names / parameters :

For example :

• If it’s GET and the URI is api/Customers/5:

  • method should start with Get

  • if it has ID so search a method which accepts int as parameter.

  • etc. (there are more rules).

I mostly believe they did it using reflection.

Question :

Isn’t it a performance hit , for every URI request – to search all this data just to attach a method ?

Where I could easily send a very short string from a client which will imply on the method on the server side ?

Why not doing it the simple way ? Ok cause we want to use http verbs as meaning. OK. but so much operations just to execute a method

example #1

get api/Customers/5

could be

a.ashx?m=gc&id=5 (method=GetCustomer & id=5)

example #2

put api/Customers/5?v=123

could be

a.ashx?m=uc&id=5?v=123' (method=UpdateCustomer & id=5 & value=123)

mine is even shorter.

Dont get me wrong. I believe this api was done by very smart people who knew what they talk about.

Just want o know what am I missing.

Answer 1

Web api has a lot of options that you don’t have with HTTP Handler if you don’t code it
Full list: http://www.asp.net/whitepapers/mvc4-release-notes#_Toc317096197

• OData support (via Queryable attribute)
• Content Negotiation
• Filters
• Model binding and validation
• Ability to self host outside of IIS
• Link generation to related resources that incorporates routing rules
• Full support for routes/routing
• Ability to create custom help and test pages using IApiExplorer

Performance comparison HttpHandler vs WebAPI: http://www.west-wind.com/weblog/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance

As always, you need to choose the the technology that suits you best, if you want performance go with Http Handler. If you want flexibility and rest go with Web API. You might want rest if you expose web services that other will consume