Skip to content
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

Enforce REST API constraints #5

Open
7 tasks
shekhargulati opened this issue Sep 12, 2020 · 5 comments
Open
7 tasks

Enforce REST API constraints #5

shekhargulati opened this issue Sep 12, 2020 · 5 comments
Assignees

Comments

@shekhargulati
Copy link
Contributor

  • Resources should be noun

  • Use kebab-case instead of camelCase for API URLs

  • Plural for resource names

  • Limit use of subresource

  • Don’t use a trailing forward slash

  • Use ResponseEntity

  • Check response status code

@shekhargulati
Copy link
Contributor Author

@awkshwayrd do you want to pick it up?

@axymthr axymthr self-assigned this Sep 12, 2020
@axymthr
Copy link

axymthr commented Sep 16, 2020

@shekhargulati Should we split up the rules classes? Right now there is just one. It could be segregated by layers.

@shekhargulati
Copy link
Contributor Author

Yes we can do that. I think it is a good idea. Should we have a rule interface that all rules should implement? We can then chain them to build the rule pipeline.

@axymthr
Copy link

axymthr commented Sep 16, 2020

Would it take us away from the basic ArchRule interface? Right now we have 1 single class defining static rules and a run-all-tests abstract test class. This allows clients to just use our defined rules. If we put in more layers we would be hiding the basic ArchUnit abstration.

@axymthr
Copy link

axymthr commented Sep 16, 2020

We could split up AbstractArchitectureTests as well, but it starts to go down YAGNI a little bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants