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

Id should not be mandatory #3

Open
hobofan opened this issue Jul 11, 2015 · 1 comment
Open

Id should not be mandatory #3

hobofan opened this issue Jul 11, 2015 · 1 comment

Comments

@hobofan
Copy link

hobofan commented Jul 11, 2015

While most objects can be Identified by an Id, some objects (e.g. on-the-fly statistics) can't be.

That's why the schemas should not have id as a required parameter:
https://github.com/storeness/api-blueprint/blob/master/schemas/single.json#L17
https://github.com/storeness/api-blueprint/blob/master/schemas/list.json#L30

@MichaelHirn
Copy link
Member

I removed the schemas completely as they turned out to be very out-of-date with the use of attributes. Schemas get created now right from the Attributes and the problem with required parameters such as id disappear. Check out 856a618

Schemas would have one advantage, that they secure a standard on a higher order. But in practice this turned out to to be too restrictive. Again the answer is hercule with Attributes. Hercule is missing at the moment the feature to transclude transclusion variables. With that we could build higher abstractions of request/response Attributes/Schemas, with which we could guarantee e.g. that a list response has a type of "list.*". But as far as I experienced it, this advantages can't justify the time that would go into providing this with hercule

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

2 participants