Proposal for new decorator to define HEAD operations
- Dominant language
- TypeScript
- Stars
- 27
- Forks
- 90
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 161
Description
### Clear and concise description of the problem
We recently worked with some HEAD operation definitions and thought that it would be useful to have a decorator that allows folks to decorate a given operation with an `@headOp` decorator, which would automatically signal that this service also supports HEAD operations for that endpoint and automatically considers all of the headers for that operation so the true definition lives in one place and it's easier to maintain the supported set of headers in one definition.
### Checklist
- [x] Follow our [Code of Conduct](https://github.com/azure/typespec-azure/blob/main/CODE_OF_CONDUCT.md)
- [x] Check that this issue is about the Azure libraries for typespec. For feature request in the typespec language or core libraries file it in the [TypeSpec repo](https://github.com/Microsoft/TypeSpec/issues/new/choose)
- [x] Read the [docs](https://azure.github.io/typespec-azure/).
- [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
Contributor guide
Research direction
The issue names no files, tests, or entry points. Start by locating existing operation decorators in the TypeSpec Azure libraries and clarify the decorator's behavior and acceptance tests; done means an @headOp decorator signals HEAD support and reuses the operation's headers from one definition.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100