Web Development

31-Aug-20 7:00

Why do we need them? What can't I just do this:

public class MyController : ApiController
{
    public void DoSomething(MyEntity entity)
    {
      MyBL myBL = new MyBL();
      myBl.DoSomethingElse(entity);
    }
}

Why do I need the Http verbs to do this?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Richard Deeming31-Aug-20 22:37

Richard Deeming

31-Aug-20 22:37

You generally want to avoid letting GET requests modify state. They should be idempotent to avoid problems with pre-fetching and caching.

Beyond that, you can use whatever verbs you like. But REST services follow a specific pattern:
Representational state transfer - Wikipedia[^]

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Kevin Marois1-Sep-20 6:01

1-Sep-20 6:01

OK. So said anything about state? What's stopping me from doing this:

public class MyController : ApiController
{
    [HttpGet]
    public void DoSomething(int id)
    {
      MyBL myBL = new MyBL();
      myBl.DeleteARecord(Id);
    }
}

I'm calling a method to delete a record in a method marked as [HttpGet].

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

Richard Deeming1-Sep-20 7:13

Richard Deeming

1-Sep-20 7:13

As I said, you should avoid doing that. Your GET method could be called multiple times. It could be pre-fetched. It could be cached.

GET requests should be idempotent, and should not affect state.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

F-ES Sitecore1-Sep-20 0:41

1-Sep-20 0:41

Every http request has a verb, that's just how http works, the verb lets the service know what action is being done, the theory being that you can use the same url to do different things. If you have the following endpoint

/product/5

then calling it with GET will return product 5's data, calling it with DELETE will delete product 5 and so on. Because all requests have a verb you have to tell .net which verbs are valid for your method.

Kevin Marois1-Sep-20 5:59

1-Sep-20 5:59

I guess I don't understand why you even need to mark up the method. What if I did this:

public class MyController : ApiController
{
    [HttpGet]
    public void DoSomething(int id)
    {
      MyBL myBL = new MyBL();
      myBl.DeleteARecord(Id);
    }
}

I've marked the method with [HttpGet], yet called a Delete method on the BL.

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

F-ES Sitecore1-Sep-20 6:35

1-Sep-20 6:35

If you do that it will fail with a 404 as the method doesn't allow that verb.

Kevin Marois1-Sep-20 7:10

1-Sep-20 7:10

Why not? There's nothing there to indicate what is does. I could name the BL method "BeHappy" and it would still run

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

F-ES Sitecore1-Sep-20 7:25

1-Sep-20 7:25

It won't work because you haven't marked it [HttpDelete]

Kevin Marois1-Sep-20 10:23

1-Sep-20 10:23

That still doesn't answer the question. The word 'delete' doesn't even exist in the method. What's stopping me from calling it?

I've called Web API methods before like TaxController's CalculateTax method. There's no HttpGet, HttpPut, HttpPost, or HttpDelete there, yet the method works.

So, again, what purpose do the verbs serve?

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

F-ES Sitecore1-Sep-20 10:33

1-Sep-20 10:33

Kevin Marois wrote:
The word 'delete' doesn't even exist in the method. What's stopping me from calling it?

If you put a non-delete verb attribute on it then the framework will stop you calling it, it will return a 404. .net has two ways of associating methods with verbs, one is the explicit adding of the attributes which will restrict what can route to that action. It also follows a naming convention so you can put the verb at the start of the action name, so GetProduct, DeleteProduct etc and .net will use that to route your calls to the right method by matching the verb with the action prefix. You can choose to follow neither convention and use bespoke names and no verb attributes and the routing will (I assume) work on the action name only.

So the purpose they serve is that if you want to following proper semantic api conventions where you route your calls to actions based on the verb then the HttpXXX attributes allow you to implement that convention if you don't want to use the names themselves to route your methods.

Kevin Marois1-Sep-20 11:09

1-Sep-20 11:09

F-ES Sitecore wrote:
If you put a non-delete verb attribute on it then the framework will stop you calling it, it will return a 404.

This is what's confusing to me. I have a Web API with NO verbs on it, and I can call it from my WPF app just fine. That's what got me posting this... what's the point of the verbs if I can create and call methods without them?
Confused | :confused:

If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.

F-ES Sitecore2-Sep-20 0:37

2-Sep-20 0:37

Supposedly if there are no verbs applied it defaults to HttpPost, so even though you didn't specify a verb, one does exist.

DerekT-P1-Sep-20 11:12

DerekT-P

1-Sep-20 11:12

It won't fail because he's suggesting calling that with HttpGet as the verb. Syntactically it's correct, but is not good practice.

I guess part of the answer is that historically, the HTTP verb played a more important part. Languages / frameworks were less flexible (or stricter?). There remain some practicalities - if you want to upload a 50Mb file, you don't want to use HttpGet because that would require the payload to be in the URL, and Http doesn't support URLs of that length. Your webserver may handle different verbs very differently, but where we're using IIS we can have ASP.Net handle different verbs - or ignore certain verbs - just how we want. For example, by default, IIS won't let you invoke a .ASMX webservice via HttpGet - but you can make a trivial change in web.config to allow it.

From RFC2616[^], part of the HTTP1.1 definition:

Quote:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Interestingly, the implication is that the end user is aware of the HTTP verbs being used in an interaction - again, a throwback to a time when internet use was the preserve of techs working at protocol level.

In short, then, the answer to the original question is simply: it's convention.

F-ES Sitecore2-Sep-20 0:34