Git Product home page Git Product logo

Comments (4)

daveshanley avatar daveshanley commented on August 18, 2024

As mentioned in #96

After attempting to solve this, I was confused as to why the correct path could not be found.

The http.Request.URL.Fragment was always missing when making a curl request or via postman etc. I was unable to perform any kind of lookup when a fragment was used, because any request made to wiretap using a fragment was just missing the fragment each time.

So then I looked a little deeper. I found this:

golang/go#3805

Fragments are never sent in HTTP.  They're purely a local browser concept.

There is no way for me determine which path is being requested when the OpenAPI specification uses a fragment as a delimiter. The fragment is never picked up by the standard library.

Which pulls into question the legitimacy of using fragments at all in OpenAPI specs. They are quite useless it seems and should not be used as delimiters for paths.

Marking this as a wontfix, because there is nothing I can do to make it work.

from wiretap.

TristanSpeakEasy avatar TristanSpeakEasy commented on August 18, 2024

@daveshanley a strategy we are seeing people using to deal with this is it effectively becomes a join of the two operations, on their servers the two routes or directed to the same handler but they are determining the operation based on the inputs, so it is effectively a oneOf between the request bodies/response bodies etc.

Totally understand if you want to keep this as wontfix, we can find some other way to deal with this but it is theoretically possible

from wiretap.

daveshanley avatar daveshanley commented on August 18, 2024

I think this strategy is a little bit odd to be honest, it means parsing the body to determine the schema, in order to figure out which fragment to use - which to me feels like a considerable hack. It feels like it's going against the spirit of the standard, in order to make it work.

from wiretap.

TristanSpeakEasy avatar TristanSpeakEasy commented on August 18, 2024

So technically yes it does look like the OpenAPI initiative has decided to not make this official OAI/OpenAPI-Specification#1635 but in the wild it is getting used to differentiate APIs that share a path but can accept different request bodies, we have come across a few cases of this and various tooling does seem to support it (including ours)

from wiretap.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.