Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requests and Responses do not have source maps #259

Closed
honzajavorek opened this issue Mar 23, 2016 · 2 comments · Fixed by apiaryio/snowcrash#376
Closed

Requests and Responses do not have source maps #259

honzajavorek opened this issue Mar 23, 2016 · 2 comments · Fixed by apiaryio/snowcrash#376
Labels

Comments

@honzajavorek
Copy link
Contributor

Currently, HTTP Requests and HTTP Responses do not have source maps in the refract output. Their sub-elements and attributes have source maps, but there's no way to determine where the actual + Request or + Response happened to be in the original document.

In following situation I can distinguish the requests, because they happen to have headers. Headers have source maps, so I can say which request was on which position:

+ Request (application/json)
+ Response 200

+ Request (application/json)
+ Response 200

However, imagine following situation with "bare" requests:

+ Request
+ Response 200

+ Request
+ Response 200

In this case the requests do not have a single sub-element with a source map (except of the method attribute, but that doesn't actually say where the + Request was written). I can say where responses were positioned, because I have source maps for the status codes. However, there is no way to say this for the requests. I can't distinguish which was which or whether they're the same and I can't re-construct number of the implicit HTTP transaction example (in this case, the first request is Example 1, the second is Example 2).

This fact blocks me to continue with apiaryio/dredd-transactions#2. I can't flawlessly implement backward compatibility for apiaryio/dredd#388 and I can't support API Elements in Dredd.

@honzajavorek
Copy link
Contributor Author

By trial and error, I found out the following cases won't allow me to reconstruct the original document. While the combinations are not often very useful on their own and sometimes they produce warnings, they're still non-erroneous API Blueprint notation which could appear in Dredd.

Problematic Cases

Bare Request

+ Request
+ Response 200

Request with Bare Attributes Section

+ Request
    + Attributes
+ Response 200

Request with Bare Headers Section

+ Request
    + Headers
+ Response 200

Request with Bare Body Section

+ Request
    + Body
+ Response 200

Request with Bare Schema Section

+ Request
    + Schema
+ Response 200

Bare Response

+ Request (application/json)
+ Response

Response with Bare Attributes Section

+ Request (application/json)
+ Response
    + Attributes

Response with Bare Headers Section

+ Request (application/json)
+ Response
    + Headers

Response with Bare Body Section

+ Request (application/json)
+ Response
    + Body

Response with Bare Schema Section

+ Request (application/json)
+ Response
    + Schema

@honzajavorek
Copy link
Contributor Author

I can confirm this has been resolved in [email protected] 🎉

honzajavorek added a commit to apiaryio/dredd-transactions that referenced this issue Apr 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants