4

I've got a Rails eCommerce project communicating with an iOS app. The iOS app receives JSON data from the Rails back-end, but there's also HTML rendering when a user comes to the project from his browser. They basically call the same actions (create, destroy, update, etc.) from both sides.

/website/my_action → HTML rendering
/website/my_action.json → API

What's the best way to organize our Rails app to stay DRY and avoid messy code / code smell ? The project currently uses respond_to a lot but i'm wondering if we shouldn't switch to a split system with default json response:

/api/v1/my_action
/website/my_action

And if so, how would you do concretely?

Here's a sample of one method in the current system

  def get_following

    @user = User.find(params[:id]) 

    respond_to do |format|
      format.html { render :index }
      format.json { render :json => ApiFormat.success(:followers, user.following) }
    end

  end

It looks fine but becomes very messy in some methods I prefer not to show. In short: how would you refacto the project in a more efficient way?

  • This is not so much a question about how to improve the code excerpt that you presented in the question. Rather, the excerpt is just a generic representative sample, and you are asking a "what is best practice?" question. Migrating from Code Review to Programmers. – 200_success Apr 26 '16 at 10:11
-2

To me it seems like it would make more sense to split them with an api namespace for all the json controllers. What did you end up doing?

| improve this answer | |
  • 1
    This is not an answer. Please post comments in the comments section. – Martin K Jan 28 at 10:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.