Q: Differentiate Save and Submit in Rest API Question on form data saving to MongoDB using Rest API. I have three different scenario.


*

*Save and return (First time saving data partially and return id for future return).

*Submit the already saved data (Second time, complete the form and do final submit, so that i can trigger other work flow.)

*Submit directly (Submit the full form first time and return the id, and start work flow)


For above scenario, i came up with below API resource
POST --> v1/applications   (This will save data and return id)
PUT --> v1/applications/{id} (This will retrieve data using id parameter and update that data)

My confusion is how to differentiate both the API, whether it is only save or final submit call, because i have to start work flow after final submission. Can i use some query parameter like below to indicate submit or save?
POST --> v1/applications?submit=true or false   (This will save data and return id)
PUT --> v1/applications/{id}?submit=true or false (This will retrieve data using id parameter and update that data)

Or do we have any better approach to differentiate save and submit within this api?

A: 
My confusion is how to differentiate both the API, whether it is only save or final submit call, because i have to start work flow after final submission. Can i use some query parameter like below to indicate submit or save?

I think it would be a lot more common to encode that signal into the body of the request, rather than trying to screw around with the URL.
PUT /applications/12345

Version: 1
Status:  Draft

PUT /applications/12345

Version: 2
Status:  Final

Keep in mind that the URI is an identifier for a resource (aka, a document).  Doing interesting work is a side effect of passing documents around.  See Jim Webber.
If you were doing everything in HTML, which doesn't natively support PUT, you would probably use POST, with one form for edits and another for finalizing, or maybe a single form designed to handle both use cases.

One question, so for first time save or direct submission first time should use POST /applications. Am i right?

That's a common choice, but not required.  The real distinction is this - are we creating the new resource at the target URL?  
If yes, then PUT, POST, PATCH are all possibilities.  
If not -- if we are sending the request to one server resource, expecting the created resource to be somewhere else, then POST is the appropriate choice.

A: In RESTFul style, query parameter means there has something differ from scenarios, which means you can't define a rule for use action. It's better to document the feature in URL than in a real document(no one will read it carefully...)
I think in your scenario it may be better like:
POST v1/applications/add/
PUT  v1/applications/{id}

BTW try not to do it perfect once time, good service needs check and maintain.
