Thanks for your work with the gem!

1. I tried omitting the URL Helpers on the --api version and ran into undefined method issues.  Also, the default_url_options also failed without the url helpers.

2. This definitely would be a very specific use case. It was more of an illustration that ASM does support rendering partials. 

3. Not sure I follow.

I do plan on covering an elasticsearch episode which is what I currently use on several apps. My only hesitation is requiring an extra dependency. I will also cover full text search on postgresql with something like pg_search. Thanks for the suggestion!

When you do something like

git flow feature start FEATURENAME

It will create a branch called feature/FEATURENAME and it will be copied from the develop branch.

From here, you can make your code changes as needed and then make your git commits as you normally would.

If you are wanting to move your work over to another computer, you can call git flow feature publish and it will create the branch on the remote repository. You can then checkout the feature on the other computer.

When all changes and commits are made, you call 

git flow feature finish #optionally passing -m 'COMMIT MESSAGE'

and this will merge your commit back into the develop branch. Alternatively, you can publish your commit again to the remote repository and then create a merge request.

By default, config/initializers/filter_parameter_logging.rb will filter the password

Rails.application.config.filter_parameters += [:password]

So, the logs would filter out the password and never be displayed in the logs. Whenever communicating with API, especially sending the password, you should always encrypt the communication with SSL. This is really no different than sending a POST request to a web login session. Unless the form is posted to an endpoint over SSL, the password would also be sent over plaintext.

Great questions!

If your application's traffic is not being served over SSL, anything that is sent or posted, would be essentially in plain text.  It was just illustrating the point that your worry about the API sending the plain text password would be the same worry for a login form. Unless the API endpoint as well as the login form are served over SSL, the password would have been sent over plaintext (and not encrypted via SSL). I suppose the confusion was plaintext. Technically, regardless, in both instances the password is sent as plaintext, but when served over an SSL connection, the plaintext password is protected.