-
Notifications
You must be signed in to change notification settings - Fork 7
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
Support OPTIONS requests #3
Comments
@erik-stephens Thanks for the detailed issue - I really appreciate it. I'm putting this at the top of the TODO since we need this meta info to be exposed for other tools we are working on. Do you know if there are any standards for the body that comes back on a OPTIONS request? If not I'll probably just use the same format from the blog post you linked. |
I don't know of any, not even defacto standards. According to RFC 2616, the format of an optional body is not defined by the spec: |
Both. Sent from my iPhone On Jun 10, 2013, at 9:56 PM, "Eric Schoffstall" <[email protected]mailto:[email protected]> wrote: @ccowanhttps://github.com/ccowan @funkytekhttps://github.com/funkytek Do you guys think we should support both OPTIONS and /_meta or just OPTIONS? — |
Agreed. |
Summary
As a developer of a crudified API, I would like client documentation auto-generated, so that client documentation is generated effortlessly and automatically kept up-to-date.
Notes
Might make sense to include other headers to help publish what the API accepts, but outside the scope for this issue. Plus, would have to be careful of impacting this OPTIONS request. For example, if wanted to publish supported auth mechanisms, then might have to publish that in the body to avoid confusing the client.
Acceptance Criteria
Allow
Accept
headerReferences
The text was updated successfully, but these errors were encountered: