Skip to main content
Software Engineering

Return to Answer

added 105 characters in body
Source Link
Dan1701
Dan1701
  • 3.1k
  • 1
  • 17
  • 25

Not sure this comes down to a hard-and-fast rule, but some decision drivers could begenerally validation is best done as early as possible. Why waste any additional time with invalid values?

Some Node-specific things to consider:

  • Are you generating routing code with Swagger or other such tools? If so, validating the URL in the Swagger is a great contract-enforcement mechanism.
  • Are you already using something like supertest to "run" your service as part of unit tests? This makes request-level validation much simpler than actually starting a service instance for each test. If not, then it makes a lot of sense to push as much validation and logic to the controller where it can be more easily tested.

Validation aside, if the API always requires year, month and day, you might consider using a standardchanging the endpoint to use the date format such as ISO-8601a filter either as a single URL parameter or perhaps apath param (startDate/api/myTag/20170907) or as a query parameter (/api/myTag?date=20170907). Nesting many parameters as in your example is not really true to the resource-identification paradigm of REST, and may prove to both a better UX and more easily tested. (But this too is not something which requires adherence to a strict set of rules).

Not sure this comes down to a hard-and-fast rule, but some decision drivers could be:

  • Are you generating routing code with Swagger or other such tools? If so, validating the URL in the Swagger is a great contract-enforcement mechanism.
  • Are you already using something like supertest to "run" your service as part of unit tests? This makes request-level validation much simpler than actually starting a service instance for each test. If not, then it makes a lot of sense to push as much validation and logic to the controller where it can be more easily tested.

Validation aside, if the API always requires year, month and day, you might consider using a standard date format such as ISO-8601 either as a single URL parameter or perhaps a startDate query parameter. Nesting many parameters as in your example is not really true to resource-identification paradigm of REST, and may prove to both a better UX and more easily tested. (But this too is not something which requires adherence to a strict set of rules).

Not sure this comes down to a hard-and-fast rule, but generally validation is best done as early as possible. Why waste any additional time with invalid values?

Some Node-specific things to consider:

  • Are you generating routing code with Swagger or other such tools? If so, validating the URL in the Swagger is a great contract-enforcement mechanism.
  • Are you already using something like supertest to "run" your service as part of unit tests? This makes request-level validation much simpler than actually starting a service instance for each test. If not, then it makes a lot of sense to push as much validation and logic to the controller where it can be more easily tested.

Validation aside, if the API always requires year, month and day, you might consider using changing the endpoint to use the date as a filter either as a path param (/api/myTag/20170907) or as a query parameter (/api/myTag?date=20170907). Nesting many parameters as in your example is not really true to the resource-identification paradigm of REST, and may prove to both a better UX and more easily tested. (But this too is not something which requires adherence to a strict set of rules).

Source Link
Dan1701
Dan1701
  • 3.1k
  • 1
  • 17
  • 25

Not sure this comes down to a hard-and-fast rule, but some decision drivers could be:

  • Are you generating routing code with Swagger or other such tools? If so, validating the URL in the Swagger is a great contract-enforcement mechanism.
  • Are you already using something like supertest to "run" your service as part of unit tests? This makes request-level validation much simpler than actually starting a service instance for each test. If not, then it makes a lot of sense to push as much validation and logic to the controller where it can be more easily tested.

Validation aside, if the API always requires year, month and day, you might consider using a standard date format such as ISO-8601 either as a single URL parameter or perhaps a startDate query parameter. Nesting many parameters as in your example is not really true to resource-identification paradigm of REST, and may prove to both a better UX and more easily tested. (But this too is not something which requires adherence to a strict set of rules).