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

Resource prototypes #16

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
159 changes: 159 additions & 0 deletions rfcs/common-data.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,159 @@
---
RFC: XXXX
Author: Egor Baranov
Status: Draft
Created: 2017-05-03
Last Modified: 2017-05-03
---

# API Blueprint RFC XXXX: Common Data

## Table of Contents

- [Abstract](#abstract)
- [Motivation](#motivation)
- [Rationale](#rationale)
- [Backwards Compatibility](#backwards-compatibility)

## Abstract

This RFC proposes an ability to add common responses and to multiple actions.

## Motivation

When you describe big API several actions can have identical responses.
For example you have 10 actions allowed for authorized user only, so each
of such actions can respond with 401. That is why you have to write same code
10 times. If you want to change this code you have to change it in 10 places.
This problem can be cause of misspellings and logical errors.
So ability to add common responses in one place for multiple actions is required.
Copy link
Member

@kylef kylef May 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think that the authentication proposal in RFC2 might be a better solution to this specific problem?

The authentication framework would allow you to annotate resources, resource group and actions that require authentication and then it would be possible to describe authentication error apart of the authentication scheme.

I think ultimately this will give API Blueprint tools better semantic information on why a specific error may occur and it can be presented better in rendered documentation. Tools such as Dredd testing tool can utilities this information to test all authenticated API actions with invalid auth tokens to verify they match the specification, this wouldn't be possible with "Common Data". Documentation can annotate which actions are authenticated to make it clearer to consumers of the API.

Copy link
Author

@goganchic goganchic May 4, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The authentication framework is a great idea, but I think that authentication is only one problem which can be solved using Common Data. Another example: we use some parter's API for several actions. Sometimes it does not work, so we return externalAPIError. It is common response but it is not connected with authentication.
Should I give another example in this document?


## Rationale

Common responses can be defined in an API Blueprint under an "Common Data" header.
Inside this header one or several Response sections are allowed.
Here is an example:

```apib
# Group Authorized resources

# Common Data
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment data section inside the group? Should it have two ## to indicate it is inside the group? Is the above group empty?


+ Response 401

## Posts [GET /posts]

+ Response 200

## Comments [GET /comments]

+ Response 200
```

This code equals to:

```apib
# Group Authorized resources

## Posts [GET /posts]

+ Response 200

+ Response 401

## Comments [GET /comments]

+ Response 200

+ Response 401
```

It is possible to have several "Common Data" sections:

```apib
# Group Authorized resources

# Common Data

+ Response 401

# Common Data

+ Response 500

## Posts [GET /posts]

+ Response 200

## Comments [GET /comments]

+ Response 200
```

This code equals to:

```apib
# Group Authorized resources

## Posts [GET /posts]

+ Response 200

+ Response 401

+ Response 500

## Comments [GET /comments]
+ Response 200

+ Response 401

+ Response 500
```

Common Data section influences to current actions group and all internal actions
groups, but not neighbors:

```apib
# Group Authorized resources

# Common Data

+ Response 401

## Posts [GET /posts]

+ Response 200

# Group Authorization

## Auth [POST /auth]

+ Response 200
```

This code equals to:

```apib
# Group Authorized resources

## Posts [GET /posts]

+ Response 200

+ Response 401

# Group Authorization

## Auth [POST /auth]

+ Response 200
```

`/auth` action has no 401 response, because it is located in separate group.

## Backwards Compatibility

If anyone use "Common Data" header in the documentation after this RFC it will
treat as special section instead of regular markdown header. If there is no
such section in the documention there will be no backward compatibility problems.