0

Front End:
The front end will have a table. Data will be populated in few columns of the table already. The user will enter the remaining columns of data. The table will have multiple rows.

There will be two buttons. SAVE and SUBMIT. SAVE button is to temporarily store data and SUBMIT will send the final data to be stored.

DB:
Each row represents a record in database table

Table & UI both looks same:

      Column1  Column2  Column3 Column4
----------------------------------------
Row1 | data   |      |  data   |
Row2 | data   |      |  data   |
Row3 | data   |      |  data   |
Row4 | data   |      |  data   |

Now, when the user click on SAVE button, I need to store the remaining column information in the database using REST API call.

What is the best way to design the REST API?

Questions in my mind,
1. If single record, I can use PATCH to do this. But multiple rows should be passed in the Request. How to frame my Request?
2. Should I use POST?
3. Should I pass all the rows as a List?
4. What if the user clicks on save multiple times? Will that increase the rest calls made and overload the network? How to efficiently handle this?

Roopashree
  • 140
  • 8

3 Answers3

1

Q1 & Q2 & Q3: You can use either PATCH or POST based on the none-functional requirements of your application( and personal preference ). Refer to the links below to understand how it can be implemented.

REST: Updating Multiple Resources With One Request - Is it standard or to be avoided?

What is the difference between PUT, POST and PATCH?

Q4: You can throttle your 'Save' button. A simple implementation would be to disable the 'Save' button once it's clicked. This can be easily achieved by Javascript. Then once you get the response from the server ( REST API response ) you can show the error message ( and reenable the 'Save' button ) or show the succuss message based on the REST API response.

Techie
  • 44,706
  • 42
  • 157
  • 243
0

My suggestion would be to create a generic route that takes in multiple rows e.g. PUT /api/datarows which would take a list of rows in the JSON body. PUT would make more sense over POST here because we are not creating new records each time the save button is hit, rather we would be updating the existing rows in the database and it should behave in an idempotent way.

As @Techie said, you could disable the save button once it is clicked to ensure it is only clicked once.

However, I would also add another recommendation here - you should keep track of what data has changed and only send those rows that were updated as opposed to sending all rows each time save is clicked. This would also solve #4 because the second time it is clicked, there will be no data that requires updating.

Only thing to watch would be if the number of rows could reach so high (several thousand) that it is too much for one request, in that case, you would need to split into multiple requests that could be distributed across nodes.

cppNoob
  • 422
  • 1
  • 5
  • 17
0

Has it been resolved? I wonder

All I know is an ajax request and a controller designed as a REST API. In fact, I have experience with handling many multi-rows, but I did not implement it with REST API. Have you set up a plan to handle multi-row while keeping the request URL and type?

This is Google Translate.

Sheraz
  • 567
  • 4
  • 22
김선호
  • 11
  • 1