Respond with ID of newly create object and ok status

Hi everyone,

A client sends a post query which contains all required data to create a
Todo except 'id'. From what I know 'id' field will be created when
@todo.save is called. So the question is how to inject id (if it is
possible and the right way) in to Controlller.create action?

Here is what I am trying to do:
  def create
    logger.info "todo#create -> #{params[:title]}"
    @todo = Todo.new(title:params[:title])
    @todo.save
    logger.info "todo#create ID: -> #{@todo.id}"
    render @todo.id.to_json(), status: :ok
  end

And I get different 500 error unless I return just a status "head :ok"
Is it a right way to use rails API? And if yes is it possible to get
back an id of created object?

I just did this last night, and here's what I used. Note that I send the whole widget back (and use JSONP to add it to the list on my page):

  def create
    @widget = Widget.new
    @widget.update_attributes(widget_params)
    render json: @widget, callback: params[:callback]
  end

Walter

Great, it did the trick.

Thank you, Walter.

Just one more question, I started googling for differences between JSON
(used in my example) and JSONP format suggested by you. I would
appreciate if you could give a couple of links or resources to read more
about JSONP, CORS or anything like that so I can get better
understanding of why my example does not work and what are alternatives
or "better ways" of implementing rails API.

Great, it did the trick.

Thank you, Walter.

Just one more question, I started googling for differences between JSON
(used in my example) and JSONP format suggested by you. I would
appreciate if you could give a couple of links or resources to read more
about JSONP, CORS or anything like that so I can get better
understanding of why my example does not work and what are alternatives
or "better ways" of implementing rails API.

The distinction comes into play when you are using JavaScript to parse the reply and update the page. If you are using a JSON API in another Rails application (or PHP, or any other server-side language) then you don't need to worry about this at all.

JavaScript interpreters all enforce a Same Origin policy, which says that a script can only access data from a site that is in the same domain, subdomain, and port as itself.

When you control both endpoints, and they don't pass the Same Origin tests, and you don't want to set up CORS, JSONP allows you to create a callback function to modify the page based on "foreign" JSON content. If you control both endpoints, and you want to set up CORS, then a traditional JSON reply is nicer, because you only rely on that endpoint to send you well-formed data, nothing else. JSONP exposes your implementation details to the API sender, and counts on that sender to reply with the callback that you indicated in your request within the body of the JSON response.

The HTML site containing these lines: https://github.com/walterdavis/api/blob/master/index.html#L117-L130 shows off both JSON (CORS) and JSONP (no CORS needed -- although my example Rails app has rack-cors installed -- it worked before I did that). Those lines are the entirety of the JSONP scheme -- one function, which takes the JSON reply from the server as its only argument, and one injected script tag to kick it all off.

Walter

Thank you, Walter!

Now it makes more sense. Hey, if this is your pet on a profile - then
you have a nice dog, it looks very friendly and funny!

That's Rosie the Racing Poodle. That photo was taken when she was about a year old, and she's 8 or 9 now, but still very friendly and active. She is a very sweet and funny dog, for sure.

Walter