0

I am working on a CRUD app where I have things called requests that can have many iterations. I have an endpoint to hit called iteration/create/requestId. When this page is hit I show an empty table with fields for the user to fill in. I take the index of the row and assign it to a field in the iteration called the iteration number. If a user were to manually enter the URL and not follow the UI then they would be able to save new iterations with duplicate iteration numbers.

My question is if I'm not following restful practices since there is assumed state that create will be called only once per request and that the iteration/edit/requestId will subsequently be called. I think I should be designing everything such that it can be hit and there will be no side effects but I'm up against a deadline and not sure what to prioritize?

  • 1
    So before creating an "iteration number", why not check to see if one already exists, and return an error if it does? – Dan Pichelman Sep 16 '16 at 14:51
  • I'm going to decide the number on the server side, thanks for the suggestion. – newbish Sep 16 '16 at 15:18
0

Why does a form I have yet to fill out need to know where it will be ultimately filed?

Decide on the number after I've done all my slow, may not ever finish, typing or you'll find yourself running out of numbers. That number is a resource you're giving away far too cheaply.

This also solves your URL hacking issue.

You seem to have some positional relationship requirement going on with rows that you were trying to solve with this preloaded number. If you can't let me submit the whole table at once for some reason then let me submit rows with numbers relative to ME. Then add whatever number you need to add to those numbers to make them relative to the server.

The kicker is that with each submission you have to consider that other people might be updating as well. So I might think I have a swath of rows all to myself then suddenly someone else submits something else in between them. If you insist on submitting a row at a time rather than my whole table at once that's just how it's going to be.

  • Thanks, I was thinking of loading existing rows if possible and basing the numbers displayed to the user off those if need be but the server number collision could still be a problem so deciding the number on the server sounds better. – newbish Sep 16 '16 at 15:17
0

I'm up against a deadline and not sure what to prioritize?

Do what you need to to ship.

Fielding in 2008

REST is software design on the scale of decades: 
every detail is intended to promote software longevity 
and independent evolution. Many of the constraints 
are directly opposed to short-term efficiency.

You should not accept the REST architectural constraints unless the properties that they introduce have value in your situation.

My question is if I'm not following restful practices since there is assumed state that create will be called only once per request and that the iteration/edit/requestId will subsequently be called.

It doesn't sound like your implementation satisfies the stateless constraint

each request from client to server must contain all 
of the information necessary to understand the request, 
and cannot take advantage of any stored context on 
the server. Session state is therefore kept entirely 
on the client.

"all of the information" basically means "no pronouns". The message provided by the client needs to explicitly describe the client's intent without any reliance on a common history.

Note that this is about understanding the message, not satisfying it. "Add a row to the current version" is bad, because the client and server may not agree what the current version is. On the other hand, "Add a row to version 7" is unambiguous; and the server can refuse the action if version 7 and the server's understanding of "current version" do not agree.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.