PATCH Request to Lithnet REST API v2 Returning 404

[ccthis]

Problem
Attempting to update MIM resource attributes via PATCH request to /v2/resources/{id} returns: 404 Not Found, despite:

• GET requests to the same endpoint working fine
• Web.config explicitly allowing PATCH verb
• Clean Lithnet REST API installation (v2.0.6692.17445)

What We've Tried
Method variations: PUT, PATCH, POST - all return 404
URL formats:

• /v2/resources/{id}
• /v2/resources/{id}/
• /v1/resources/{id} (V1 API)

Web.config fixes:

• Removed WebDAV handler and module
• Fixed handler ordering
• Restored clean original Lithnet configuration

IIS configuration:

• Verified ExtensionlessUrlHandler supports all verbs including PATCH
• Verified UrlRoutingModule enabled
• Verified handlers process requests

Current State

• GET /v2/resources/{id} → 200 OK ✅
• PATCH /v2/resources/{id} → 404 Not Found ❌
• Authentication working (Kerberos from browser)
• Payload correctly formatted JSON

Question
Is the PATCH endpoint for updating resources supposed to work on /v2/resources/{id}, or is there a different endpoint/format required? Documentation shows PATCH with JSON body should work, but requests return 404 despite the resource existing (proven by successful GET).

Ref 1: https://github.com/lithnet/resourcemanagement-webservice/wiki/Update-a-resource
Ref 2: https://github.com/lithnet/resourcemanagement-webservice/wiki/Add-a-value-to-a-specific-attribute-of-a-resource

Environment: Server 2019, Lithnet ResourceManagement WebService v2.0.6692.17445 on IIS with Basic Auth over HTTPS

Thank you for all the hard work!

[KentNordstrom]

I have not tested it, but could 404 also be the response if the attribute you try to update does not exist. I would start by validating with a GET that the attribute name, I try to use in the PATCH call, is correctly spelled.

[ccthis]

Kent,

Thanks for the suggestion — attribute names are correct (exact match from GET, case-sensitive).

Proof

GET /v2/resources/{id} → 200 OK

"OfficeFax": "45685464755",
"TimeZone": "aae31da6-69c7-4704-b3c8-4702326f6c47"

PATCH /v2/resources/{id} → 404 Not Found

{ "OfficeFax": "41285464755" }

(Same for TimeZone)

---

Confirmed

• Account: Domain Admin + MIM Admin + IIS Admin → full rights

---

Docs Say

PATCH /v2/resources/{id} with JSON → update attributes
https://github.com/lithnet/resourcemanagement-webservice/wiki/Update-a-resource

---

Why 404?

Resource exists, attribute exists, verb allowed, URL matches.

Is there:

• A required body wrapper?
• A hidden routing rule returning 404 instead of 400?

Happy to share web.config, screenshots, etc.

Thanks!

[KentNordstrom]

I cannot directly see what you might be missing in your environment...

Below is a snippet from PS scripts I have used before to update, PATCH, users via MIM REST API V2... I never use Basic Auth, but it does not seem like you issue is related to Credentials/Authentication. I am in the middle of building a new MIM SP3 lab environment, I will see if I can verify my old "code" still work in that one.

#Update User
$Body = @{attributeName=$attributeValue} | ConvertTo-Json -Compress
$UpdateUserUri = $MIMRESTUri + $User.ObjectID
Invoke-RestMethod -Method Patch -Uri $UpdateUserUri -Body $Body -UseDefaultCredentials -Headers @{"Content-Type" = "application/json"}

[ryannewington]

If PUT PATCH and POST are not working, something must be intercepting the request in the IIS pipeline and causing that. If you can get the request, you shouldn't be getting a 404 on a PATCH PUT or POST.

It's a bit hard to say exactly what it could be, but give @KentNordstrom's PowerShell query a try just to rule out a problem with the caller.

Could it be a HTTP/1 vs HTTP/2 problem?

[ccthis]

I'm going to deploy a fresh server and retest. Ill share the diff/results next week sometime. Thanks!