Skip to content

Use consistent HTTP methods for updates and invite replies - #166

Open
martsokha wants to merge 1 commit into
mainfrom
refactor/http-method-consistency
Open

Use consistent HTTP methods for updates and invite replies#166
martsokha wants to merge 1 commit into
mainfrom
refactor/http-method-consistency

Conversation

@martsokha

Copy link
Copy Markdown
Member

Summary

An audit of HTTP methods across the handlers found two inconsistencies; this fixes both.

1. Update endpoints: PUT → PATCH

Connection, policy, and webhook updates were registered as PUT, but their request DTOs are entirely Option fields and the handlers do partial merges (..Default::default(), omitted field = unchanged) — i.e. PATCH semantics mislabeled as PUT. The other seven update endpoints (account, member, file, pipeline, workspace, notification settings, api token) already use PATCH. Switched these three so all ten agree.

2. Invite replies: consistent status + body

The two invite-reply endpoints diverged even though both accept-paths create a membership:

  • reply_to_invite (by id): returned 200 + Invite
  • reply_to_invite_code (by code): returned 201 + Member

Aligned reply_to_invite with reply_to_invite_code: 201 + Member on accept, 200 + None on decline. The same action now reports the same result regardless of which path a client uses, and the accept path no longer hides the created membership behind a 200 + Invite.

Notes

Reviewed but deliberately left unchanged (defensible, not bugs): POST /members/leave/ (a distinct self-service action, DELETE is reserved for admin-remove which forbids self-removal), and the action POSTs (test webhook, redact run, generate code, detect run).

Breaking for clients calling the old PUT update routes or relying on the old invite-reply shape — acceptable pre-release.

Verification

  • cargo clippy --all-targets --all-features --workspace -- -D warnings
  • cargo +nightly fmt --all -- --check
  • RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features --workspace
  • cargo test --all-features -p nvisy-server

🤖 Generated with Claude Code

Two API-method inconsistencies surfaced by an audit:

- Connection, policy, and webhook updates were registered as PUT, but
  their DTOs are all-optional and the handlers do partial merges (omitted
  fields left unchanged) — PATCH semantics. Switch them to PATCH so all
  update endpoints agree (the other seven already used PATCH).

- The two invite-reply endpoints diverged: replying by id returned
  200 + Invite while replying by code returned 201 + Member, even though
  both accept paths create a membership. Align reply-by-id with
  reply-by-code: 201 + Member on accept, 200 + None on decline, so the
  same action reports the same result regardless of path.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@martsokha martsokha added refactor code restructuring without behavior change server API handlers, middleware, auth labels Aug 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

refactor code restructuring without behavior change server API handlers, middleware, auth

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant