RESTful Data Structure Structures

Question

I tried Google and searched everywhere, but could not find the ultimate authority on this topic. Being true to REST principles, how can I configure the HTTP interface for:

• Ordered list (get, add, insert, position, reorder, remove)

• Set (get, add, remove)

• Hash table (get, add, remove)

NOTE These data structures must contain references to existing resources with known identifiers.

Answer 1

What would I do for an ordered list and hash table. I think the methods will be the same for the set and list:

Ordered list

Get item 123:

GET /list/123 

Add item to list:

 POST /list/ 

Insert a new item at position 5:

 POST /list/?position=5 

Move item 123 to position 3:

 PUT /list/123?position=3 

Delete item 123:

 DELETE /list/123 

Delete item at position 3:

 DELETE /list/?position=3 

Of course, your API should update the indices of all elements when inserting and deleting.

Hash table

Get the element "somekey":

 GET /hashtable/somekey 

Add the "somekey" element:

 POST /hashtable/somekey 

Delete the element "somekey":

 DELETE /hashtable/somekey 

Answer 2

@dadads

You cannot define such an interface directly.

Ordered list (get, add, insert, position, reorder, remove)

Excluding "insert into position" and "reorder", you can ideally implement "get", "add" and "remove", for example:

• You define your resource / service / users
• You can use POST / service / users to add a new user to the "users" collection
• You can get / service / users to get users
• You can get / service / users / user-id to get a specific user.
• You can DELETE / service / users / user-id from the user collection.

This is a very crude example, although it does describe some ideas. In order to achieve "reordering" and "insert into position", you need to implement your own action semantics, which you can include in the presentation of your resource, and let the client know HOW to perform these operations. As a reference, you can see this suggestion of the JSON PATCH specification: https://tools.ietf.org/html/rfc6902 , which attempts to describe such operations.

There is no need to use an existing media format, you can define your own under your own namespace, for example: application / vnd.your-company.format-name + json, which describes these features and also advertises this information to customers.

Answer 3

You must separate the transport mechanism from the main application. I would think about developing the application correctly, and then figure out how to access it through HTTP. Thus, you can easily add or change transport mechanisms (SOAP, SCA, etc.) without affecting the main application.

Once you have developed the application correctly, consider accessing it from HTTP requests through something like an adapter or visitor template.

Answer 4

This is my idea for reordering.

There is an HTTP PATCH method that is used to update resource fragments. Give the resource a new index property, then make a call using the PATCH method

 PATCH /collection [ { "id: "original index 0" "index": 1 } { "id: "original index 1" "index": 0 } ] 

Then your server server should figure out how to do this atomically. But, in my opinion, this is the best way to stay true RESTful.

Alternatively, there is a better solution, but it may not apply to all cases. Since ordering always depends on some criteria, it can even be as simple as the insertion order. Let your collection URL support the orderBy query orderBy , and let this orderBy dictate how the result is ordered. Then, during your reordering of the call from the customer, simply update the resource property used for the order criteria.

Answer 5

I came up with this question, basically looking for a RESTful way to reorder. I don’t really like any of the answers, so this is what I consider the most RESTful.

To reorder, you can make an order a resource:

/list/order

Then you can perform normal operations on it (for these examples, take a list with 5 elements located in it):

 "items":" [ { "id": "A", "name": "Monkey" }, { "id": "B", "name": "Cow" }, { "id": "C", "name": "Horse" }, { "id": "D", "name": "Turkey" }, { "id": "E", "name": "Tasmanian Devil" }, ] 

Note that "order" is not included in the response of the resource. It is not needed - the order is implicitly determined by the order in which the elements respond.

GET /list/order

returns a list of item identifiers in the correct order

['A','B','C','D','E']

POST /list/order with payload ['D','B','C','A','E']

GET /list/order

returns a list of item identifiers in the correct order

['D','B','C','A','E']

It is also obvious that you will return the items in the list in the correct order when you execute GET on /list .

GET /list

returns a list of items in the correct order

 "items":" [ { "id": "D", "name": "Turkey" }, { "id": "B", "name": "Cow" }, { "id": "C", "name": "Horse" }, { "id": "A", "name": "Monkey" }, { "id": "E", "name": "Tasmanian Devil" }, ]