CODEWITHSUNDEEP
c#.netasp.net-mvcvisual-studiorest
Alex Gordon
Alex Gordon

Reputation: 60711

Does RESTful design prefer [FromBody] tag?

Does RESTful design prefer data in the URL or [FromBody]?

Suppose I have a controller method:

[Route("ServiceActivity({serviceActivityGuid:guid})/State({serviceAppointmentState:int})/Status({statusCode:int})", Name = "ServiceActivityStateStatusPut")]
[HttpPut]
[NotNull]
public ServiceAppointment ServiceActivityStateStatusPut(int serviceAppointmentState, int statusCode, Guid serviceActivityGuid)
{
    return this.serviceActivityService.UpdateShowTimeAs(serviceAppointmentState, statusCode, serviceActivityGuid);
}

Would it be preferable to do something like this instead?

    [Route("ServiceActivity({serviceActivityGuid:guid})", Name = "ServiceActivityStateStatusPut")]
    [HttpPut]
    [NotNull]
    public ServiceAppointment ServiceActivityStateStatusPut([FromBody] myObject)
    {
        return this.serviceActivityService.UpdateShowTimeAs(myObject);
    }

The behavior of this should be that when client navigates to:

../ServiceActivity({serviceActivityGuid:guid})/State({serviceAppointmentState:int})/Status({statusCode:int})

specifically:

../ServiceActivity(BF6ACF8D-8967-4D2B-BF53-E112D15A609B)/State(1)/Status(0)

Then it should set the the State to 1 and the Status to 0 for the record with primary key BF6ACF8D-8967-4D2B-BF53-E112D15A609B.

Does RESTful design prefer data in the URL or [FromBody]?

Upvotes: 2

Views: 81

Answers (1)

Carson
Carson

Reputation: 1189

REST is all about resources. The idea behind it is that your access points should correlate to a resource specifically.

Before I start, know that REST and HTTP are not required to work together, so RESTsul services do not need to use HTTP and HTTP does not need to be RESTful.

In your example, I would say that, I personally would prefer a [FromBody] simply because you could redesign your URL scheme to be more RESTful. REST itself does not prefer [FromBody] because that is an HTTP construct in ASP.NET

For example, your resource in the above example appears to be a ServiceActivity so having a URL like /ServiceActivity/{serviceActivityGuid:guid} for the PUT method may make more sense. The actual routine would look like your second one.

If your first example was a GET then I would say it was closer to what REST prefers, but since it is a PUT I don't think it makes much sense. I would interpret the first example as saying that we are going to update the status of the state of the service activity. So while your first one isn't necessarily 'wrong' per se, it gives me the wrong idea about what resource is actually being affected.

As an aside, I would also look at your URL formatting. In my opinion, using the Resource({id}) format does not appear to be inline with common practice for REST with HTTP. I would look into a format like /Resource/{id}/Subresource/{id} etc.

If you do have a GET that requires you to query on the state and the status I would do something like /ServiceActivity?state=1&status=0 to return all of the activities with a state of 1 and a status of 0.

Some good resources on REST can be found here, here, and here

Hope this helps :)

EDIT Another good question on REST and HTTP that doesn't exactly answer yours, but seems like a good resource.

Upvotes: 1

Related Questions