Respond with ID of newly create object and ok status

Rails
1

Hi everyone,

A client sends a post request which contains all required data to create
a Todo item except its ‘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?

2

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

3

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 me 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.

4

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!

5

On May 25, 2015, at 4:15 PM, Taras M. [email protected] wrote:

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:

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

6

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