CODEWITHSUNDEEP
rest
Trevor
Trevor

Reputation: 10993

Is my example 'introducing state' or otherwise contravening REST / OData standards?

I'm in the process of implementing a HTTP interface on an embedded device to allow remote control of the device through REST requests. The REST API has been specified by a partner company responsible for creating the remote control software. On my side, everything is written in C on a tight memory constraint, meaning that the REST interface needs to couple easily and closely to how the device operates.

My problem is that the way that the embedded device fundamentally works doesn't quite fit the REST interface they've specified. I've responded with a proposal that would work from my point of view, but their developer has simply replied that it "introduces state" and "would no longer be REST".

My following example will illustrate what they wanted to do originally.

A GET to a given resource path would return one or more JSON objects as follows. Each object has a truly unique index, plus a group number it belongs to, plus a state.

[
    {
        "index" : "123",
        "group" : "2",
        "someState" : "false"
    },

    {
        "index" : "124",
        "group" : "2",
        "someState" : "false"
    },

    {
        "index" : "125",
        "group" : "3",
        "someState" : "false"
    },

]

A PUT to that resource path and that object's index, e.g. some\resource-123 changes the state of that object, such that someState would now be true.

A DELETE to that resource and index would 'delete' the object entirely.

Now, the issue I have is that, because of how the device works, you can DELETE objects individually, but you can only PUT -- i.e. flip the someState -- of all objects at once in a given group. That's determined by how the embedded device behaves - and it is fundamental behaviour that cannot be changed.

My proposal is that a PUT could not be made to a resource and index; it would have to be made to the resource and group. For example, a PUT to some\resource-2 would set the someState of the first two objects in the above array. This would then work fine from the point of view of the remote control's UI and we could all be happy. But the developer cries No! It isn't REST!!!!1one and rejects my idea.

How have I "introduced state" by proposing this?

If what I have proposed is bad and kittens will indeed die because of it, is there a better way that I could present the objects as a REST resource and allow their states to be changed given the above constraints?

Upvotes: 1

Views: 26

Answers (1)

Eric Stein
Eric Stein

Reputation: 13682

It sounds like all objects in a group must have the same state? If so, I would suggest you ask them to expose the groups as an endpoint, with someState as a group property. That should alleviate their concern about introducing state, and let you set state on a group level. Individual objects could still expose state as a read-only property.

GET /groups/3
{
   "id": 3,
   "someState": true
}
PUT /groups/3  <!-- sets the state of all objects in the group -->
{
   "id": 3,
   "someState": false
}
GET /objects/5
{
        "index" : "123",
        "group" : "2",
        "someState" : "false"
}

Upvotes: 3

Related Questions