Specify inputs in documentation for ImageHandler

[akainth015]

Description

Just the title, specify the MIME types that the ImageHandler accepts so that they don't have to be found in Swagger.

Motivation and Context

This change helps developers discover the features in ImageHandler without having to set it up, build their service, open it in Swagger, and then browse the available MIME types.

How Has This Been Tested?

Rebuilt the documentation and verified that the changes show up correctly.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Documentation
• Test, CI, or build
• None

Components (if applicable)

• BentoService (model packaging, dependency management, handler definition)
• Model Artifact (model serialization, multi-framework support)
• Model Server (mico-batching, logging, metrics, tracing, benchmark, OpenAPI)
• YataiService (model management, deployment automation)
• Documentation

Checklist:

• My code follows the bentoml code style, both ./dev/format.sh and
  ./dev/lint.sh script have passed
  (instructions).
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• My change requires a change in bentoml/gallery example notebooks
• I have sent a pull request to bentoml/gallery to make that change

[pep8speaks]

Hello @akainth015, Thanks for updating this PR.

There are currently no PEP 8 issues detected in this PR. Cheers! 🍻

Comment last updated at 2020-06-11 00:06:29 UTC

[parano]

Hi @akainth015 just to provide some context - there are active refactoring going on around the API handler code path, see the pinned issue #736

The ImageHandler in release 0.7.8 is actually the LegacyImageHandler in the master branch. In the current master branch's ImageHandler, we removed the capability to received multiple images at the same time, and plan to add a separate MultiImageHandler for that purpose. This makes it a lot easier for the user to run inference jobs from CLI with image files as input. In the new ImageHandler, when posting form-data request, the "image_file" name in the swagger input definition actually can be anything, since the handler is expecting only one image file uploaded per request. This behavior is similar in the LegacyImageHandler, when it is used for handling single image input.

[codecov]

Codecov Report

Merging #780 into master will increase coverage by 0.01%.
The diff coverage is 68.08%.

@@            Coverage Diff             @@
##           master     #780      +/-   ##
==========================================
+ Coverage   55.33%   55.34%   +0.01%     
==========================================
  Files         108      108              
  Lines        8158     8143      -15     
==========================================
- Hits         4514     4507       -7     
+ Misses       3644     3636       -8     

Impacted Files	Coverage Δ
bentoml/yatai/deployment/operator.py	61.53% <0.00%> (+8.20%)	⬆️
bentoml/yatai/deployment/sagemaker/wsgi.py	0.00% <0.00%> (ø)
bentoml/yatai/repository/s3_repository.py	25.75% <25.75%> (ø)
bentoml/yatai/client/deployment_api.py	17.30% <33.33%> (ø)
bentoml/yatai/deployment/aws_lambda/operator.py	58.73% <58.73%> (ø)
bentoml/yatai/yatai_service_impl.py	33.83% <75.00%> (ø)
bentoml/yatai/repository/local_repository.py	75.75% <75.75%> (ø)
bentoml/yatai/deployment/sagemaker/operator.py	80.20% <80.20%> (ø)
bentoml/yatai/repository/repository.py	83.33% <83.33%> (ø)
bentoml/yatai/validator/deployment_pb_validator.py	95.00% <95.00%> (ø)
... and 7 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bf4ea37...8e47ae7. Read the comment docs.

[akainth015]

Ah, alright. That makes a lot of sense! Do you think I should just close this pull request, or update the documentation for LegacyImageHandler?

[parano]

@akainth015 I think it's probably better to close the PR for now and wait until the API handler refactoring work is merged since it probably will change things around both files. @bojiang is currently working on that and expect the initial PR to come out in a day or two.