New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rails api #19832

Merged
merged 60 commits into from Jun 11, 2015

Conversation

Projects
None yet
@dhh
Member

dhh commented Apr 20, 2015

[Description extracted from http://wyeworks.com/blog/2015/4/20/rails-api-is-going-to-be-included-in-rails-5/]

A decision was made to incorporate Rails API into Rails core πŸŽ‰ πŸŽ‰ πŸŽ‰.

What Is Rails API?

The original idea behind Rails API was to serve as a starting point for a version of Rails better suited for JS-heavy apps. As of today, Rails API provides: trimmed down controllers and middleware stack together with a matching set of generators, all specifically tailored for API type applications.

Next steps

We still need to discuss the β€œRails way” for API applications, how API apps should be built and, what features we’d like included from our original list of ideas. In particular:

  • Do we want to avoid asset generation in Rails by having a back-end and a front-end apps?
  • Do we prefer to have a single application and keep asset generation in Rails instead?
  • Do we like Active Model Serializers better than Jbuilder?
  • If not, can we make Rails API play nicely with Jbuilder?
@ZhangHanDong

This comment has been minimized.

Show comment
Hide comment
@ZhangHanDong

ZhangHanDong Apr 21, 2015

Good job, although I have been using Rails Metal for my Api.

ZhangHanDong commented Apr 21, 2015

Good job, although I have been using Rails Metal for my Api.

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Apr 21, 2015

Member

Hey @dhh, thanks for opening the PR.
We need to discuss a lot of stuff about this, I've written a short blog post that also has links for a previous article I've written in the past http://wyeworks.com/blog/2015/4/20/rails-api-is-going-to-be-included-in-rails-5/

Some of the things that needs discussions are ...

  • Would we like to have a backend app and a frontend app and then avoid assets generation in Rails?
  • Would we prefer to have just one app and keep assets generation in Rails?
  • Would we like to include Active Model Serializers by default or jbuilder?
  • How this will play nicely when used with jbuilder?
Member

spastorino commented Apr 21, 2015

Hey @dhh, thanks for opening the PR.
We need to discuss a lot of stuff about this, I've written a short blog post that also has links for a previous article I've written in the past http://wyeworks.com/blog/2015/4/20/rails-api-is-going-to-be-included-in-rails-5/

Some of the things that needs discussions are ...

  • Would we like to have a backend app and a frontend app and then avoid assets generation in Rails?
  • Would we prefer to have just one app and keep assets generation in Rails?
  • Would we like to include Active Model Serializers by default or jbuilder?
  • How this will play nicely when used with jbuilder?
# Prevent CSRF attacks by raising an exception.
# For APIs, you may want to use :null_session instead.
protect_from_forgery with: :exception
<%- end -%>

This comment has been minimized.

@guilleiguaran

guilleiguaran Apr 21, 2015

Member

What about that advice:

# For APIs, you may want to use :null_session instead.

Don't we want to do that for APIs?

@guilleiguaran

guilleiguaran Apr 21, 2015

Member

What about that advice:

# For APIs, you may want to use :null_session instead.

Don't we want to do that for APIs?

This comment has been minimized.

@hammerdr

hammerdr Apr 21, 2015

Contributor

null_session should be an explicit choice, I think. If you have a API endpoint that doesn't have any parameters to validate, the null_session will still execute the endpoint. Exception is safer.

@hammerdr

hammerdr Apr 21, 2015

Contributor

null_session should be an explicit choice, I think. If you have a API endpoint that doesn't have any parameters to validate, the null_session will still execute the endpoint. Exception is safer.

This comment has been minimized.

@georgeclaghorn

georgeclaghorn Apr 21, 2015

Member

Doesn't seem to make sense for a controller in an API-only app to have cross-site request forgery protection. Also, from the docs, API controllers do not have session handling:

An API Controller is different from a normal controller in the sense that by default it doesn't include a number of features that are usually required by browser access only: layouts and templates rendering, cookies, sessions, flash, assets, and so on.

@georgeclaghorn

georgeclaghorn Apr 21, 2015

Member

Doesn't seem to make sense for a controller in an API-only app to have cross-site request forgery protection. Also, from the docs, API controllers do not have session handling:

An API Controller is different from a normal controller in the sense that by default it doesn't include a number of features that are usually required by browser access only: layouts and templates rendering, cookies, sessions, flash, assets, and so on.

This comment has been minimized.

@hammerdr

hammerdr Apr 21, 2015

Contributor

Many APIs would want CSRF protection. This includes single page javascript applications.

null_session isn't the same thing as a browser session, but is instead more like an 'empty' request. It's more like passing a NullObject to a controller instead of raising an exception. The benefit of doing so is that you have more explicit control over the actions regarding that request on a per action basis. With exceptions, you're handling the exception in a more generic location (controller level instead of action level).

Not all of this is 100% verified, just off of my memory. Apologies if I got something wrong.

@hammerdr

hammerdr Apr 21, 2015

Contributor

Many APIs would want CSRF protection. This includes single page javascript applications.

null_session isn't the same thing as a browser session, but is instead more like an 'empty' request. It's more like passing a NullObject to a controller instead of raising an exception. The benefit of doing so is that you have more explicit control over the actions regarding that request on a per action basis. With exceptions, you're handling the exception in a more generic location (controller level instead of action level).

Not all of this is 100% verified, just off of my memory. Apologies if I got something wrong.

This comment has been minimized.

@georgeclaghorn

georgeclaghorn Apr 21, 2015

Member

Sorry, I misunderstood! Was thinking in the context of a public API. Thanks for correcting me. πŸ˜„

@georgeclaghorn

georgeclaghorn Apr 21, 2015

Member

Sorry, I misunderstood! Was thinking in the context of a public API. Thanks for correcting me. πŸ˜„

This comment has been minimized.

@jsanders

jsanders Apr 21, 2015

Contributor

I'm not sure if there's a consensus on this, or what that consensus is if it exists, but I think it still makes sense to use a cookie for authentication when serving an API to a client using AJAX through a browser, because you can use an HttpOnly cookie, which javascript can't access, rather than local storage, which it can. If you're doing that, then CSRF protection is still important.

Having said that, it doesn't look (based on your quote) like API controllers will be using cookie-based sessions by default, so maybe they don't need CSRF protection by default either.

Edit: Wrote this before seeing @hammerdr's comment – I'll leave it here anyway, but it might be irrelevant.

@jsanders

jsanders Apr 21, 2015

Contributor

I'm not sure if there's a consensus on this, or what that consensus is if it exists, but I think it still makes sense to use a cookie for authentication when serving an API to a client using AJAX through a browser, because you can use an HttpOnly cookie, which javascript can't access, rather than local storage, which it can. If you're doing that, then CSRF protection is still important.

Having said that, it doesn't look (based on your quote) like API controllers will be using cookie-based sessions by default, so maybe they don't need CSRF protection by default either.

Edit: Wrote this before seeing @hammerdr's comment – I'll leave it here anyway, but it might be irrelevant.

This comment has been minimized.

@spastorino

spastorino Apr 21, 2015

Member

It doesn't need CSRF protection, we are not adding session stuff on this configuration.
The comment is still valid for regular Rails applications where you can build APIs, for those APIs maybe null_session is a good idea. For Rails API's apis you don't need this kind of stuff.

@spastorino

spastorino Apr 21, 2015

Member

It doesn't need CSRF protection, we are not adding session stuff on this configuration.
The comment is still valid for regular Rails applications where you can build APIs, for those APIs maybe null_session is a good idea. For Rails API's apis you don't need this kind of stuff.

@rafaelfranca rafaelfranca added this to the 5.0.0 milestone Apr 21, 2015

@chancancode

This comment has been minimized.

Show comment
Hide comment
@chancancode

chancancode Apr 21, 2015

Member

@rwz you might have opinions on some of the open questions?

Member

chancancode commented Apr 21, 2015

@rwz you might have opinions on some of the open questions?

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Apr 21, 2015

Member

Agree on keeping assets out of the app. Need to take another (long over
due) look at AMS. But regardless of whether we go with AMS or jbuilder as
default, both should be totally equal and trivial to swap between.

On Tue, Apr 21, 2015 at 5:08 PM, Santiago Pastorino <
notifications@github.com> wrote:

BTW, because I left some open questions without answers, my take on those
is ...

Would we like to have a backend app and a frontend app and then avoid
assets generation in Rails?
Yes. So Rails should only generate the API and completely skip assets
generation.

Would we prefer to have just one app and keep assets generation in
Rails?
No.

Would we like to include Active Model Serializers by default or
jbuilder?
AMS.

How this will play nicely when used with jbuilder?
It should work.

But given that the questions could be a bit controversial I left it there
to be able to discuss.

β€”
Reply to this email directly or view it on GitHub
#19832 (comment).

Member

dhh commented Apr 21, 2015

Agree on keeping assets out of the app. Need to take another (long over
due) look at AMS. But regardless of whether we go with AMS or jbuilder as
default, both should be totally equal and trivial to swap between.

On Tue, Apr 21, 2015 at 5:08 PM, Santiago Pastorino <
notifications@github.com> wrote:

BTW, because I left some open questions without answers, my take on those
is ...

Would we like to have a backend app and a frontend app and then avoid
assets generation in Rails?
Yes. So Rails should only generate the API and completely skip assets
generation.

Would we prefer to have just one app and keep assets generation in
Rails?
No.

Would we like to include Active Model Serializers by default or
jbuilder?
AMS.

How this will play nicely when used with jbuilder?
It should work.

But given that the questions could be a bit controversial I left it there
to be able to discuss.

β€”
Reply to this email directly or view it on GitHub
#19832 (comment).

#
# class MetalController
# ActionController::API.without_modules(:Redirecting, :DataStreaming).each do |left|
# include left

This comment has been minimized.

@rafaelfranca

rafaelfranca Apr 22, 2015

Member

Why leaving the include for the users since it is only what they can do? I think we should implement it for ourself and just require users to do:

ActionController::API.without_modules(:Redirecting, :DataStreaming)
@rafaelfranca

rafaelfranca Apr 22, 2015

Member

Why leaving the include for the users since it is only what they can do? I think we should implement it for ourself and just require users to do:

ActionController::API.without_modules(:Redirecting, :DataStreaming)

This comment has been minimized.

@spastorino

spastorino Apr 22, 2015

Member

This feature already exists in Base so I wouldn't change the current API

@spastorino

spastorino Apr 22, 2015

Member

This feature already exists in Base so I wouldn't change the current API

This comment has been minimized.

@rafaelfranca

rafaelfranca Apr 22, 2015

Member

πŸ‘

@rafaelfranca
@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Apr 22, 2015

Member

I remember that in our original patch we had a really great guide about this feature and I think it would be really great if we could get it back.

About the questions agree with @dhh.

Member

rafaelfranca commented Apr 22, 2015

I remember that in our original patch we had a really great guide about this feature and I think it would be really great if we could get it back.

About the questions agree with @dhh.

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Apr 22, 2015

Member

@spastorino and, great implementation bro.

Member

rafaelfranca commented Apr 22, 2015

@spastorino and, great implementation bro.

run_generator
assert_file "Gemfile" do |content|
assert_no_match(/gem 'coffee-rails'/, content)

This comment has been minimized.

@Davidslv

Davidslv Apr 22, 2015

Maybe just use the name of the gems instead, if someone uses double quotes it will not match

@Davidslv

Davidslv Apr 22, 2015

Maybe just use the name of the gems instead, if someone uses double quotes it will not match

This comment has been minimized.

@guilleiguaran

guilleiguaran Apr 22, 2015

Member

This is testing here just against the default generated Gemfile that use single quote as convention, so this is fine.

@guilleiguaran

guilleiguaran Apr 22, 2015

Member

This is testing here just against the default generated Gemfile that use single quote as convention, so this is fine.

@guilleiguaran

This comment has been minimized.

Show comment
Hide comment
@guilleiguaran

guilleiguaran Apr 22, 2015

Member

@dhh Let me know if you have any concerns or recommendations about AMS API, right now that we're open for discussion and planning for the new version!!!

Member

guilleiguaran commented Apr 22, 2015

@dhh Let me know if you have any concerns or recommendations about AMS API, right now that we're open for discussion and planning for the new version!!!

@jipiboily

This comment has been minimized.

Show comment
Hide comment
@jipiboily

jipiboily Apr 22, 2015

Contributor

FWIW, here are my 2 cents.

I personally would by far prefer ActiveModel Serializers, but as long as we can swap them, I would be fine.

I think, that I would keep the assets generation out of API apps by default, but make it possible. I think most people using Rails as an API are more likely to have a separate setup for their front end, like using Gulp & Grunt or any other cool JS stuff there is.

Whatever the decisions are, I am very happy to see Rails API in Rails 5! Thanks for all the hard work on this (and everything else).

Contributor

jipiboily commented Apr 22, 2015

FWIW, here are my 2 cents.

I personally would by far prefer ActiveModel Serializers, but as long as we can swap them, I would be fine.

I think, that I would keep the assets generation out of API apps by default, but make it possible. I think most people using Rails as an API are more likely to have a separate setup for their front end, like using Gulp & Grunt or any other cool JS stuff there is.

Whatever the decisions are, I am very happy to see Rails API in Rails 5! Thanks for all the hard work on this (and everything else).

@ralph

This comment has been minimized.

Show comment
Hide comment
@ralph

ralph Apr 22, 2015

I'd argument for keeping asset compilation/concatenation/etc. out of the API app.

If you are writing a JS app, you'd rather use a JS toolchain to prepare the assets. Also, many JS frameworks come with their own build tools, like EmberJS and Angular 2.0. Furthermore, developers working on the JS app exclusively don't have to install a Ruby AND a JS env, if you provide them an API server for development.

ralph commented Apr 22, 2015

I'd argument for keeping asset compilation/concatenation/etc. out of the API app.

If you are writing a JS app, you'd rather use a JS toolchain to prepare the assets. Also, many JS frameworks come with their own build tools, like EmberJS and Angular 2.0. Furthermore, developers working on the JS app exclusively don't have to install a Ruby AND a JS env, if you provide them an API server for development.

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Apr 22, 2015

Member

@rafaelfranca putting the guide back is in my todo list :)

Member

spastorino commented Apr 22, 2015

@rafaelfranca putting the guide back is in my todo list :)

@yuki24

This comment has been minimized.

Show comment
Hide comment
@yuki24

yuki24 Apr 24, 2015

Contributor

I've used both ActiveModel Serializer and jbuilder pretty heavily and have never been a happy user of AMS. much prefer jbuilder.

Contributor

yuki24 commented Apr 24, 2015

I've used both ActiveModel Serializer and jbuilder pretty heavily and have never been a happy user of AMS. much prefer jbuilder.

spastorino added a commit that referenced this pull request Jun 11, 2015

@spastorino spastorino merged commit 21f7bcb into rails:master Jun 11, 2015

1 check was pending

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
@bf4

This comment has been minimized.

Show comment
Hide comment
@bf4

bf4 Jun 11, 2015

Contributor

@spastorino Awesome! Would you be interested in me writing a PR along the lines of https://groups.google.com/d/topic/rubyonrails-core/K8t4-DZ_DkQ/discussion (as discussed above)?

Contributor

bf4 commented Jun 11, 2015

@spastorino Awesome! Would you be interested in me writing a PR along the lines of https://groups.google.com/d/topic/rubyonrails-core/K8t4-DZ_DkQ/discussion (as discussed above)?

@joaomdmoura

This comment has been minimized.

Show comment
Hide comment
@joaomdmoura

joaomdmoura Jun 11, 2015

Amazing! Really happy you made it! Let's keep up the good work!

joaomdmoura commented Jun 11, 2015

Amazing! Really happy you made it! Let's keep up the good work!

@claudiob

This comment has been minimized.

Show comment
Hide comment
@claudiob

claudiob Jun 11, 2015

Member

πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘

Member

claudiob commented Jun 11, 2015

πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘

@ajoy39

This comment has been minimized.

Show comment
Hide comment
@ajoy39

ajoy39 Jun 12, 2015

Great work!Β 

β€”
Sent from Mailbox

On Thu, Jun 11, 2015 at 4:04 PM, Claudio B. notifications@github.com
wrote:

πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘

Reply to this email directly or view it on GitHub:
#19832 (comment)

ajoy39 commented Jun 12, 2015

Great work!Β 

β€”
Sent from Mailbox

On Thu, Jun 11, 2015 at 4:04 PM, Claudio B. notifications@github.com
wrote:

πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘ πŸ‘

Reply to this email directly or view it on GitHub:
#19832 (comment)

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jun 12, 2015

Member

🀘

Member

dhh commented Jun 12, 2015

🀘

@gfvcastro

This comment has been minimized.

Show comment
Hide comment
@gfvcastro

gfvcastro Jun 13, 2015

Contributor

Excellent. πŸ‘ πŸŽ‰

Contributor

gfvcastro commented Jun 13, 2015

Excellent. πŸ‘ πŸŽ‰

@vestimir

This comment has been minimized.

Show comment
Hide comment
@vestimir

vestimir commented Jun 13, 2015

πŸ––

@robin850

This comment has been minimized.

Show comment
Hide comment
@robin850

robin850 Jun 23, 2015

Member

(ping #20612)

Member

robin850 commented Jun 23, 2015

(ping #20612)

@yosriady

This comment has been minimized.

Show comment
Hide comment
@yosriady

yosriady Jun 23, 2015

Brilliant! 🎊

yosriady commented Jun 23, 2015

Brilliant! 🎊

@robertomiranda

This comment has been minimized.

Show comment
Hide comment
@robertomiranda

robertomiranda Jun 23, 2015

Contributor

❀️

Contributor

robertomiranda commented on ebcc15c Jun 23, 2015

❀️

@Justin-lu

This comment has been minimized.

Show comment
Hide comment
@Justin-lu

Justin-lu commented Jun 28, 2015

🀘

@spuyet

This comment has been minimized.

Show comment
Hide comment
@spuyet

spuyet Jun 29, 2015

πŸ‘

spuyet commented Jun 29, 2015

πŸ‘

@aalizzwell58

This comment has been minimized.

Show comment
Hide comment
@aalizzwell58

aalizzwell58 Jun 30, 2015

Good job πŸ‘

aalizzwell58 commented Jun 30, 2015

Good job πŸ‘

@Theminijohn

This comment has been minimized.

Show comment
Hide comment
@Theminijohn

Theminijohn commented Jun 30, 2015

πŸ‘

@hapiben

This comment has been minimized.

Show comment
Hide comment
@hapiben

hapiben commented Jun 30, 2015

Sweet!

@seemsindie

This comment has been minimized.

Show comment
Hide comment
@seemsindie

seemsindie Jul 1, 2015

Ok, i have to ask, how i can use this now?

seemsindie commented Jul 1, 2015

Ok, i have to ask, how i can use this now?

@bf4

This comment has been minimized.

Show comment
Hide comment
@bf4

bf4 Jul 1, 2015

Contributor

@dhh @spastorino lock comments, please?

Contributor

bf4 commented Jul 1, 2015

@dhh @spastorino lock comments, please?

@robin850

This comment has been minimized.

Show comment
Hide comment
@robin850

robin850 Jul 1, 2015

Member

@seemsindie : You have to use Rails' master ; this is not yet released.

@bf4 : Yes, you're right!

Member

robin850 commented Jul 1, 2015

@seemsindie : You have to use Rails' master ; this is not yet released.

@bf4 : Yes, you're right!

@rails rails locked and limited conversation to collaborators Jul 1, 2015

@rails rails unlocked this conversation Jul 2, 2015

@spastorino

This comment has been minimized.

Show comment
Hide comment

@rails rails locked and limited conversation to collaborators Jul 2, 2015

require 'test_helper'
<% module_namespacing do -%>
class <%= controller_class_name %>ControllerTest < ActionController::TestCase

This comment has been minimized.

@dhh

dhh Dec 4, 2015

Member

We should replace this with an ActionDispatch::IntegrationTest generator instead. ActionController::TestCase is legacy ware.

@dhh

dhh Dec 4, 2015

Member

We should replace this with an ActionDispatch::IntegrationTest generator instead. ActionController::TestCase is legacy ware.

This comment has been minimized.

@spastorino

spastorino Dec 7, 2015

Member

πŸ‘ will take a look at it

@spastorino

spastorino Dec 7, 2015

Member

πŸ‘ will take a look at it

@rafaelfranca rafaelfranca modified the milestones: 5.0.0 [temp], 5.0.0 Dec 30, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.