Skip to content

C
Cvat

疯人忠 / Cvat

通知 1
Star 0
Fork 0
C
Cvat

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 06 4月, 2023 1 次提交
  3. 05 4月, 2023 3 次提交
  5. 04 4月, 2023 4 次提交
  7. 01 4月, 2023 1 次提交
  9. 31 3月, 2023 3 次提交
  11. 30 3月, 2023 2 次提交
  13. 29 3月, 2023 5 次提交
    • M
      Fix SDK documentation problems (#5903) · a9e8225f
      由 Maxim Zhiltsov 提交于 
      Resolves #5871
Related: https://github.com/opencv/cvat/issues/5847,
https://github.com/opencv/cvat/issues/5814

This PR makes SDK examples valid Python code and adds some missing info.

- Fixed incorrect method names in examples
- Added missing `api_client.` use in method examples
- Fixed invalid return types in examples
- Fixed imports in examples
- Added notes about binary files in low-level API, extra method args and
returned values
- Removed html escapes from method and field descriptions
- Changed function signatures to be closer to the most popular variants
      a9e8225f
    • R
      Remove support for redundant request media types in the API (#5874) · 409fac52
      由 Roman Donchenko 提交于 
      Currently, every API endpoint that takes a request body supports (or at
least declares to support) 4 media types:

* `application/json`
* `application/offset+octet-stream`
* `application/x-www-form-urlencoded`
* `multipart/form-data`

Supporting multiple media types has a cost. We need to test that the
various media types actually work, and we need to document their use
(e.g., providing examples for each supported type). In practice, we
mostly don't... but we still need to. In addition, the user, seeing the
list of supported types, has to decide which one to use.

Now, the cost could be worthwhile if the multiple type support provided
value. However, for the most part, it doesn't:

* `application/offset+octet-stream` only makes sense for the TUS
endpoints. Moreover, for those endpoints it's the only type that makes
sense.

* `application/x-www-form-urlencoded` is strictly inferior to JSON. It
doesn't support compound values, and it doesn't carry type information,
so you can't, for example, distinguish a string from a null. It's
potentially susceptible to CSRF attacks (we have protections against
those, but we could accidentally disable them and not notice). Its main
use is for form submissions, but we don't use HTML-based submissions.

* `multipart/form-data` shares the downsides of
`application/x-www-form-urlencoded`, however it does have a redeeming
quality: it allows to efficiently upload binary files. Therefore, it has
legitimate uses in endpoints that accept such files.

Therefore, I believe it is justified to reduce the API surface area as
follows:

* Restrict `application/offset+octet-stream` to TUS endpoints and remove
support for other types from those endpoints.

* Remove `application/x-www-form-urlencoded` support entirely.

* Restrict `multipart/form-data` support to endpoints dealing with file
uploads.

Note that I had to keep `multipart/form-data` support for `POST
/api/cloudstorages` and `PATCH /api/cloudstorages/<id>`. That's because
they accept a file-type parameter (`key_file`). I don't especially like
this. Key files are not big, so the efficiency benefits of
`multipart/form-data` don't matter. Therefore, I don't think we really
need to support this type here; it would be more elegant to just use
JSON and Base64-encode the key file contents. However, I don't have time
to make that change right now, so I'm
leaving it for another time.
      409fac52
    • A
      Fix export of a job from a task with multiple jobs (#5928) · ce635657
      由 Anastasia Yasakova 提交于 
      Fixed #5927
      ce635657
    • M
      minor documentation fixes (#5932) · c988357e
      由 Mariia Acoca 提交于
      c988357e
    • M
      Fix formatting script (#5944) · 0a9881f0
      由 Maxim Zhiltsov 提交于
      0a9881f0
  15. 28 3月, 2023 3 次提交
  17. 27 3月, 2023 7 次提交
  19. 25 3月, 2023 5 次提交
  21. 24 3月, 2023 6 次提交