lunny/git-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove mention of extended transfers in v1 api docs, in v1.3 docs

Browse Source
This commit is contained in:
Steve Streeting 2016-07-08 11:02:19 +01:00
parent c25d4ddf2d
commit 7c35e9c348
1 changed files with 0 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
docs/api/v1/http-v1-batch.md
View File

@ -285,65 +285,3 @@ track usage.
Some server errors may trigger the client to retry requests, such as 500, 502,
503, and 504.
## Extended upload & download protocols
By default it is assumed that all transfers (uploads & downloads) will be
performed via a singular HTTP resource and that the URLs provided in the
response are implemented as such. In this case each object is uploaded or
downloaded in its entirety through that one URL.
However, in order to support more advanced transfer features such as resuming,
chunking or delegation to other services, the client can indicate in the request
its ability to handle other transfer mechanisms.
Here's a possible example:
```json
{
"operation": "upload",
"accept-transfers": "tus,resumable.js",
"objects": [
{
"oid": "1111111",
"size": 123
}
]
}
```
The `accept-transfers` field is a comma-separated list of identifiers which the
client is able to support, in order of preference. In this hypothetical example
the client is indicating it is able to support resumable uploads using either
the tus.io protocol, or the resumable.js protocol. It is implicit that basic
HTTP resources are always supported regardless of the presence or content of
this item.
If the server is able to support one of the extended transfer mechanisms, it can
provide resources specific to that mechanism in the response, with an indicator
of which one it picked:
```json
{
"transfer": "tus",
"objects": [
{
"oid": "1111111",
"size": 123,
"actions": {
"upload": {
"href": "https://my.tus.server.com/files/1111111"
}
}
}
]
}
```
In this case the server has chosen [tus.io](http://tus.io); in this case the
underlying transport is still HTTP, so the `href` is still a web URL, but the
exact sequence of calls and the headers sent & received are different from a
single resource upload. Other transfers may use other protocols.
__Note__: these API features are provided for future extension and the examples
shown may not represent actual features present in the current client).