[Admin API] Find a request that matched a given mapping #562

Closed
opened 2025-12-29 08:30:14 +01:00 by adam · 14 comments
Owner

Originally created by @tlevesque-ueat on GitHub (Dec 12, 2023).

Originally assigned to: @StefH on GitHub.

Maybe I'm missing something, but I can't find a way to find a request that matched a mapping, given the mapping GUID, using the Admin API.

The request body for the POST /__admin/requests/find endpoint takes a RequestModel, but MappingGuid is a property of LogEntryModel, so it doesn't seem like I can do it using this endpoint.

The GET /__admin/requests/{guid} endpoint takes the GUID of the request, not the mapping, so it's not helpful since I don't know the request GUID.

Is there anyway to achieve what I want? It would be very useful, to avoid repeating the whole request specification to verify if a request was made.

As a workaround, I currently use GET /__admin/requests and check against the whole list to see if a request matched the mapping, but it's not ideal.

Originally created by @tlevesque-ueat on GitHub (Dec 12, 2023). Originally assigned to: @StefH on GitHub. Maybe I'm missing something, but I can't find a way to find a request that matched a mapping, given the mapping GUID, using the Admin API. The request body for the `POST /__admin/requests/find` endpoint takes a `RequestModel`, but `MappingGuid` is a property of `LogEntryModel`, so it doesn't seem like I can do it using this endpoint. The `GET /__admin/requests/{guid}` endpoint takes the GUID of the request, not the mapping, so it's not helpful since I don't know the request GUID. Is there anyway to achieve what I want? It would be very useful, to avoid repeating the whole request specification to verify if a request was made. As a workaround, I currently use `GET /__admin/requests` and check against the whole list to see if a request matched the mapping, but it's not ideal.
adam added the feature label 2025-12-29 08:30:14 +01:00
adam closed this issue 2025-12-29 08:30:15 +01:00
Author
Owner

@StefH commented on GitHub (Dec 12, 2023):

@tlevesque-ueat

Some possible options to solve this;

  1. I can add a new GET request like requests?mappingGuid=123abc
  2. I can add the MappingGuid as nullable Guid to the RequestModel

What would be the best design?

@StefH commented on GitHub (Dec 12, 2023): @tlevesque-ueat Some possible options to solve this; 1. I can add a new GET request like `requests?mappingGuid=123abc` 2. I can add the MappingGuid as nullable Guid to the RequestModel What would be the best design?
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 12, 2023):

Hi,

Thanks for your reply.

The MappingGuid isn't logically part of the RequestModel, so adding it there would be a bit of a hack.
Ideally, the "find requests" endpoint would take an LogEntryModel, not a RequestModel, but that would be a breaking change...
I think a query parameter, as suggested in your first option, would be fine.

@tlevesque-ueat commented on GitHub (Dec 12, 2023): Hi, Thanks for your reply. The `MappingGuid` isn't logically part of the `RequestModel`, so adding it there would be a bit of a hack. Ideally, the "find requests" endpoint would take an `LogEntryModel`, not a `RequestModel`, but that would be a breaking change... I think a query parameter, as suggested in your first option, would be fine.
Author
Owner

@StefH commented on GitHub (Dec 13, 2023):

@tlevesque-ueat
I can update the server code to support both the current RequestModel and the LogEntryModel as an input model. That would not introduce a breaking change.

@StefH commented on GitHub (Dec 13, 2023): @tlevesque-ueat I can update the server code to support both the current `RequestModel` _and_ the `LogEntryModel` as an input model. That would not introduce a breaking change.
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 13, 2023):

I can update the server code to support both the current RequestModel and the LogEntryModel as an input model. That would not introduce a breaking change.

On the same endpoint? How would it differentiate between the two?
If possible, it would be perfect. And add an overload to the FindRequestsAsync method in IWireMockAdminApi

@tlevesque-ueat commented on GitHub (Dec 13, 2023): > I can update the server code to support both the current `RequestModel` _and_ the `LogEntryModel` as an input model. That would not introduce a breaking change. On the same endpoint? How would it differentiate between the two? If possible, it would be perfect. And add an overload to the `FindRequestsAsync` method in `IWireMockAdminApi`
Author
Owner

@StefH commented on GitHub (Dec 16, 2023):

@tlevesque-ueat
I decided for the mappingGuid.

See PR:
https://github.com/WireMock-Net/WireMock.Net/pull/1043

An preview version 1.5.44-ci-18104 can be tested.
(https://github.com/WireMock-Net/WireMock.Net/wiki/MyGet-preview-versions)

@StefH commented on GitHub (Dec 16, 2023): @tlevesque-ueat I decided for the mappingGuid. See PR: https://github.com/WireMock-Net/WireMock.Net/pull/1043 An preview version `1.5.44-ci-18104` can be tested. (https://github.com/WireMock-Net/WireMock.Net/wiki/MyGet-preview-versions)
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 18, 2023):

That's perfect, thanks!
However I can't really test the preview, because I use the container version of WireMock.NET, which isn't updated yet, as far as I can tell.
I don't suppose you publish preview versions of the Docker container?

@tlevesque-ueat commented on GitHub (Dec 18, 2023): That's perfect, thanks! However I can't really test the preview, because I use the [container version](https://github.com/WireMock-Net/WireMock.Net-docker) of WireMock.NET, which isn't updated yet, as far as I can tell. I don't suppose you publish preview versions of the Docker container?
Author
Owner

@StefH commented on GitHub (Dec 18, 2023):

I don't suppose you publish preview versions of the Docker container?

No, I do not have anything setup in the pipeline to also build a preview versions for docker versions.

@StefH commented on GitHub (Dec 18, 2023): > I don't suppose you publish preview versions of the Docker container? No, I do not have anything setup in the pipeline to also build a preview versions for docker versions.
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 18, 2023):

It's OK, I'll wait for the non-preview release. I have a workaround, so I'm not in a hurry.

@tlevesque-ueat commented on GitHub (Dec 18, 2023): It's OK, I'll wait for the non-preview release. I have a workaround, so I'm not in a hurry.
Author
Owner

@StefH commented on GitHub (Dec 22, 2023):

@tlevesque-ueat
A new version from the docker is published.

@StefH commented on GitHub (Dec 22, 2023): @tlevesque-ueat A new version from the docker is published.
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 22, 2023):

Awesome, thanks! Will try it now

@tlevesque-ueat commented on GitHub (Dec 22, 2023): Awesome, thanks! Will try it now
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 22, 2023):

It works fine, thanks!

Just one thing, though: it only returns one request, but there could be multiple requests that match the same mapping GUID... It would probably be better to return a collection of requests. I'll make some comments on the PR.

I should have reviewed more carefully when you made the PR, sorry about that...

@tlevesque-ueat commented on GitHub (Dec 22, 2023): It works fine, thanks! Just one thing, though: it only returns one request, but there could be multiple requests that match the same mapping GUID... It would probably be better to return a collection of requests. I'll make some comments on the PR. I should have reviewed more carefully when you made the PR, sorry about that...
Author
Owner

@StefH commented on GitHub (Dec 22, 2023):

You can also create a PR yourself for that.

@StefH commented on GitHub (Dec 22, 2023): You can also create a PR yourself for that.
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 22, 2023):

Sure, I will. If you don't mind the breaking change (hopefully the new endpoint is recent enough that nobody is already relying on it...)

@tlevesque-ueat commented on GitHub (Dec 22, 2023): Sure, I will. If you don't mind the breaking change (hopefully the new endpoint is recent enough that nobody is already relying on it...)
Author
Owner

@tlevesque-ueat commented on GitHub (Dec 22, 2023):

https://github.com/WireMock-Net/WireMock.Net/pull/1046

@tlevesque-ueat commented on GitHub (Dec 22, 2023): https://github.com/WireMock-Net/WireMock.Net/pull/1046
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/WireMock.Net#562