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

Support OPTIONS requests #3

Open
erik-stephens opened this issue Jun 10, 2013 · 5 comments
Open

Support OPTIONS requests #3

erik-stephens opened this issue Jun 10, 2013 · 5 comments

Comments

@erik-stephens
Copy link

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

  • Respond to OPTIONS requests on collections with:
    • Supported methods in the Allow
    • Acceptable content types in the Accept header
    • Documentation for the resource in the body.
  • Support the following content types:
    • text (markdown format)
    • text/html
    • application/json (in case someone wants to auto-include in existing docs)

References

@yocontra
Copy link
Member

@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.

yocontra pushed a commit that referenced this issue Jun 10, 2013
@erik-stephens
Copy link
Author

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:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

@yocontra
Copy link
Member

@ccowan @funkytek Do you guys think we should support both OPTIONS and /_meta or just OPTIONS?

@simianhacker
Copy link
Contributor

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?


Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-19242846.

@erik-stephens
Copy link
Author

Agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants