Does Pact net supports application/json-patch+json content type ?

[gyuvaraj10]

I am currently not able to create contracts for the API calls that takes JsonPatchDocument object as body in PATCH request. Although I tried to build the body (JsonPatchDocument) using ExpandoObject Pact is considering the body content type as application/json only.

Can someone please help? looks none of our services that has got JsonPatchDocument object can be tested.

[adamrodger]

This isn't supported in the v4 beta; only application/json currently is. It may be possible to add though given the body itself is still JSON.

[mefellows]

Pact should support this content type (it's still valid JSON, it's just a specific shape). If it doesn't, it's a bug and should be fixed.

[gyuvaraj10]

This is not supported

[gyuvaraj10]

reopened as it is a bug

[mefellows]

I am currently not able to create contracts for the API calls that takes JsonPatchDocument object as body in PATCH request. Although I tried to build the body (JsonPatchDocument) using ExpandoObject Pact is considering the body content type as application/json only.

Can you please explain in more detail what you mean by this? At the moment, we don't have enough information to understand the problem, let alone how we would solve it.

Ideally, we'd like to see the consumer test code and, if the problem is on the provider side, the error you are seeing there.

Best case - a reproducible code base we can download, run and witness the problem first hand.

--

This function looks like it should properly detect the content type: https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_models/src/content_types.rs#L87-L91

  /// If it is a JSON type
  pub fn is_json(&self) -> bool {
    self.main_type == "application" && (self.sub_type.starts_with("json") ||
      self.suffix.as_ref().unwrap_or(&String::default()) == "json" ||
      self.sub_type == "graphql")
  }

(I've just updated the tests adding this content type in it, and can confirm it correctly identifies it as JSON). Is it that the

[adamrodger]

@mefellows the problem is that @gyuvaraj10 is using an ASP.Net Core extension (which is non-standard and looks half-abandoned to me, but whatever):

https://docs.microsoft.com/en-us/aspnet/core/web-api/jsonpatch?view=aspnetcore-6.0

It is theoretically possible to support that given it's just JSON, but in PactNet we expect that all JSON bodies have the content type application/json:

https://github.com/pact-foundation/pact-net/blob/0ea980d20f1ea7437f132145a4e7944417ae04b6/src/PactNet/RequestBuilder.cs#L313-L325

That means if you establish a consumer test it'll expect application/json but then the real client call will use a different content type (the patch one) and thus fail to match the mock server properly.

We can't add an overload which takes JsonPatchDocument directly because that would introduce a dependency on the above library (which we can't do because of incompatible framework types) but we could maybe add an overload which allows the content type to be specified by the user instead of hard-coded.

It's a very niche problem though for sure. I'm not 100% sold on allowing the user to override the content type because it's not validated in PactNet at all (given it currently doesn't need to be, since it's not user-supplied). You could specify text/plain or literally anything and it just wouldn't make sense. The point of the typed overloads was that we could ensure that everything was definitely valid (and add further content types and stuff later on, like adding a WithXmlBody or something).

I've also mulled over adding a WithJsonPatchBody overload, but that would be cumbersome to use. It'd have to take a dynamic and you'd have to write all the matchers yourself. The specification isn't exactly huge, but it'd still be awkward for each user to need to implement it.

Perhaps an extension library which adds support for specifying JsonPatch bodies and also contains all the matchers is the way to go. I'm really not sure on this one, there doesn't appear to be a neat solution.

Edit: Just an edit to say that this isn't a bug - it's just something that's not currently supported in PactNet and is thus an enhancement. How that's actually implemented is the dilemma here.

[mefellows]

Hmm if I understand this correctly, it means other forms of JSON won't be supported either e.g. application/ld+json?

we could maybe add an overload which allows the content type to be specified by the user instead of hard-coded

This seems the most sensible. JSON is the predominant use case so it makes sense for it to be a first class API, but being able to specify a concrete media type in other use cases is going to be needed.