ruby-grape / ruby-grape/grape

Required params at the top level namespace, is this possible?

Open
#1,842 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature request
Dominant language
Ruby
Stars
10k
Forks
1.2k
Avg merge
14h 38m
Merged PRs (30d)
92

Description

My code is currently like this:

    namespace :top_level do
      namespace :child_one do
        params do
          requires :token, :type => String
          requires :id, :type => String
        end

        mount V1::Controllers::ChildOneController
      end

      namespace :child_two do
        params do
          requires :token, :type => String
          requires :id, :type => String
          requires :name, :type => String
          requires :description, :type => String
        end

        mount V1::Controllers::ChildTwoController
      end

As both child_one and child_two routes require token and id, is it possible to move them up to the top_level namespace? I tried the following but it doesn't seem to work:

    namespace :top_level do
      params do
        requires :token, :type => String
        requires :id, :type => String
      end

      namespace :child_one do
        mount V1::Controllers::ChildOneController
      end

      namespace :child_two do
        params do
          requires :name, :type => String
          requires :description, :type => String
        end

        mount V1::Controllers::ChildTwoController
      end

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the nested namespace and params-block examples from the issue in a local Grape API. Read the namespace and parameter-validation entry points to determine whether parent parameters are inherited; done means establishing the supported behavior or documenting that top-level required parameters cannot apply to both mounted child routes.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
api
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.