This repository has been archived by the owner on Nov 8, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 10
Add support for defining hypermedia affordances #19
Open
smizell
wants to merge
2
commits into
apiaryio:master
Choose a base branch
from
smizell:smizell/add-affordances
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,8 @@ | ||
# Changelog | ||
All notable changes to the Refract project will be documented in this file. | ||
|
||
## Master | ||
- Add support for [affordances](https://github.com/apiaryio/api-elements/issues/18) | ||
|
||
## [1.0.0-rc1] | ||
- Initial production-ready version of API Elements |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -189,6 +189,10 @@ Note: At the moment only the HTTP protocol is supported. | |
The value of `relation` attribute SHOULD be interpreted as a link relation | ||
between transition's parent resource and the transition's target resource | ||
as specified in the `href` attribute. | ||
|
||
If a custom relation is being used, it SHOULD be defined using an | ||
Affordance Element, and the value of the `relation` property SHOULD be | ||
the `id` of the defined affordance. | ||
|
||
- `href` (Templated Href) - The URI template for this transition. | ||
|
||
|
@@ -211,6 +215,7 @@ Note: At the moment only the HTTP protocol is supported. | |
Definition of any input message-body attribute for this transition. | ||
|
||
- `contentTypes` (array[String]) - A collection of content types that MAY be used for the transition. | ||
|
||
- `content` (array) | ||
- (Copy) - Transition description's copy text. | ||
- (HTTP Transaction) - An instance of transaction example. | ||
|
@@ -234,6 +239,49 @@ Note: At the moment only the HTTP protocol is supported. | |
} | ||
``` | ||
|
||
### Affordance (Base API Element) | ||
|
||
An affordance element provides a way to provide affordance definitions for the | ||
API. These definitions can describe link relations used in a Transition Element, | ||
along with defining unsafe and idempotent transitions. | ||
|
||
While data structures are used for defining semantics around data models, | ||
affordances are used for defining semantics around hypermedia state transitions. | ||
|
||
The control types used here are based on the types used in [ALPS][]. The meta | ||
property `id` SHOULD be used to define the machine-usable name of the | ||
affordance. | ||
|
||
#### Properties | ||
|
||
- `element`: affordance | ||
- `attributes` | ||
- `controlType` (enum) | ||
- safe - A hypermedia control that triggers a safe, idempotent state | ||
transition (e.g. HTTP.GET or HTTP.HEAD). | ||
- unsafe - A hypermedia control that triggers an unsafe, non-idempotent | ||
state transition (e.g. HTTP.POST). | ||
- idempotent - A hypermedia control that triggers an unsafe, idempotent | ||
state transition (e.g. HTTP.PUT or HTTP.DELETE). | ||
- `content` (array) | ||
- (Copy) | ||
|
||
#### Example | ||
|
||
```json | ||
{ | ||
"element": "affordance", | ||
"meta": { | ||
"id": "self", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See comment below. |
||
"title": "Self" | ||
}, | ||
"attributes": { | ||
"controlType": "safe" | ||
}, | ||
"content": [] | ||
} | ||
``` | ||
|
||
### Category (Base API Element) | ||
|
||
Grouping element – a set of elements forming a logical unit of an API such as | ||
|
@@ -260,6 +308,7 @@ transitions. | |
- scenario - Category is set of steps. | ||
- transitions - Category is a group of transitions. | ||
- authSchemes - Category is a group of authentication and authorization scheme definitions | ||
- affordances - Category is a group of affordances | ||
- `attributes` | ||
- `meta` (array[Member Element]) - Arbitrary metadata | ||
|
||
|
@@ -531,6 +580,11 @@ HTTP response message. | |
- `element`: httpResponse (string, fixed) | ||
- `attributes` | ||
- `statusCode` (number) - HTTP response status code. | ||
- `content` (array) | ||
- (Affordance) - Expected affordance for the given payload | ||
|
||
The Ref Element MAY be used to reference existing affordances defined | ||
elsewhere. | ||
|
||
## Data Structure Elements | ||
|
||
|
@@ -1756,6 +1810,7 @@ These elements and definitions are referenced as part of the base Refract specif | |
[MSON]: https://github.com/apiaryio/mson | ||
[MSON Reference]: https://github.com/apiaryio/mson/blob/master/MSON%20Reference.md | ||
[Refract]: https://github.com/refractproject/refract-spec/blob/master/refract-spec.md | ||
[ALPS]: https://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-01#section-2.2.12 | ||
|
||
[API Description Elements]: definitions/api-description-elements.md | ||
[Data Structure Elements]: definitions/data-structure-elements.md | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the names here are good. Both
GET
andDELETE
are idempotent. So, just sayingidempotent
is not enough.What if we make
controlType
an array of enum?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this borrows from what has already been done by Mike Amundsen and others in ALPS. It appears they get around this with overloading the "idempotent" term to mean an "unsafe, idempotent" control. This would mean that you would use
safe
forGET
andidempotent
forDELETE
. Conversely,idempotent
in this scenario would not be applied toGET
.I'm going to reach out to Mike and others about this, because I think you bring up a good point. While what we have solves the problem you mention, it is a little confusing to say "idempotent" must also be "unsafe." It may be better to do an enum and let users decide how they describe it.
But one note on that—it may require that
idempotent
always has eithersafe
orunsafe
with it if this is to support automatically mapping to other protocols. I'm betting that's why they went the direction they did.I'll post what I find here and we can chat about where to go from there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are conversing through emails, I wouldn't mind being cced on them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pksunkara done!
https://groups.google.com/forum/?fromgroups=#!topic/alps-io/ji-7UM-c5P0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pksunkara in my email, I listed two options we have in addition to the ALPS way:
Another option is to make up our own terms and categories. I just mention that here because it might be something good to just think about. However I can't come up with anything right now :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pksunkara per my discussions on the mailing list, I think it would be best to remove this
controlType
attribute and think through it in another issue/PR. Thoughts?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think the way they are overriding the keywords
unsafe
andidempotent
is confusing and shouldn't be done. I actually like your proposal of boolean attributes. My only concern regarding that is whether "safe + non-idempotent" exists and/or makes sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually curious if there is something we could do differently with this to make it better. I think I agree with your concern here and think we should move away from it. I have a few thoughts on that along with yours, and I think it would be better to discuss specifically rather than just here in comments.
Thanks for bringing this up. Good catch on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am okay with separating the discussion about this. Please feel free to create an issue and remove the relevant parts from here.