Modeling Operations in a REST Service

Question

I know that these questions have been asked before. I have a solution for my problem, and I want to know if I violate REST or HTTP rules somewhere.

On my system, I have a resource called member that supports the usual GET/POST/PUT operations. Member has Active and Disabled status. I need to simulate a user disconnect operation. I understand why the following would be a bad idea in terms of REST

 POST api/member/john.smith/disable 

I read a decision to accept a resource that represents a request to disable an element, something like below

 public class DisableMemberRequest { public string Username {get; set;} } 

And then POST on the resource above

 POST api/DisableMemberRequest 

Although this approach sounds reasonable, I believe that this is not the case in terms of pure APIs. It may be debatable whether the response to the above request should be 200 OK or 201 Created or 202 Accepted .

I think I would break up a new resource called DisabledMember , and PUT on that resource would mean that a specific member should be disabled, as shown below

 PUT api/disabledmember/john.smith 

This looks like the absolutely correct design from a REST / HTTP perspective for me. But I am not an expert and would like to confirm this with people who have been doing this for a long time.

EDIT

I am adding this data after interacting with other programmers on this page. The process of disconnecting a member is not only setting the status flag on the member. There are other workflows that need to be started when a member is disconnected.

Answer 1

One way I like to do this is to define a resource that represents a set of disabled members. To disconnect a member, you add this member to the set of disconnected members. It might look something like this.

 POST /api/DisabledMembers Content-Type: text/uri-list http://example.org/api/members/john.smith 

If you want to cancel the operation, you can do

 POST /api/ActiveMembers Content-Type: text/uri-list http://example.org/api/members/john.smith 

This approach has the advantage that doing GET /api/DisabledMembers would be completely natural. In addition, using text/uri-list it becomes easy to disable / re-activate a set of elements at the same time.

Answer 2

Your first two sentences smell a bit because they have a verb in the URL. A good RESTful architecture defines only noun resources, since the HTTP protocol defines a set of verbs applicable to these resources.

Another suggestion is interesting, but PUT suggests you do a GET to get an idea of ​​the thing you just put in, which doesn't make much sense in this context.

From what you are saying, there is a significant process of enabling or disabling a user account and that you are not comfortable working with PUT or PATCH to simply “flip” the value from true to false . If this takes some time, has a transitional state and is likely to be what you want to provide consumers with APIs so that they know about this process, it makes sense to define the process itself as a kind of resource:

Start deactivation:

 POST api/members/deactivations 

Get the current status of a deactivation or report on actions that have occurred:

 GET api/members/deactivations/john.smith 

To cancel decontamination in the process (optional):

 DELETE api/members/deactivations/john.smith 

If you can reactivate an account, it can follow a similar pattern.

If you think that in these workflows there is not enough money to justify them as your own resources or you just don’t know what to answer to GET , then this means that the workflow is not so significant that it cannot just hide from API users and run as a side effect of changing the value of the active user.

Answer 3

Just answered a similar question in here .

A practical way of thinking or applying REST as a starting point (at least this works for me) is this:

1) Use only HTTP 'GET / POST / PUT / DELETE as a way to simulate the actions of your domain. As with a database, all your actions are mapped to CURD .

2) The URI / URL should identify only resources. There should never be any action in your URI.

3) The data exchange must be in the body of HTTP messages. Just to simplify discussions, not to simulate the data itself

The tragedy solution looks clean.

Updated for @ Suhas comment address

REST is not a naming convention. It's all about how to think about resources, not about actions when developing a REST API. Always have to think about the "Nonce" resource, as in the URL / URI. You already have all the CURD actions that must be mapped to the domain actions and manage them in the URL.

I like the Tragedian solution, just for the sake of discussion, we can reorganize the Tragedian solution with a similar set of nonce and a different URL pattern to better match the use of different domains. The following may not be the best solution for the domain, but they are equivalent to RESTful.

Remove Membership

• DELETE api / membership / [member-id] /

Get member status

• GET api / membership / [member-id] / status /

Add Membership

• POST api / membership / [member-id] /

Updated to resolve "DisabledMember" as a resource

If you use "PUT DisabledMember" to make "disconnect a member" as suggested by Suhas Then what do the following actions in the "DisabledMember" resource mean?

DELETE DisabledMember -> Activate it again

POST DisabledMember → ??

GET DisabledMember is just one ☺

In this design, it actually “masks” the “disable in resource” action. You can still make her do what you want, but it will not be as useful to me.

Answer 4

User has Active and Disabled status.

Thus, the status is a property of the member's object / resource; in this case, why don't you just want to use the PUT method on the Member resource with the status set to Disabled?

Answer 5

If this is a short process to disconnect a user, why not use the HTTP PATCH?

See the answer to a similar question.