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

Customize requests and results type #456

Closed
amischler opened this Issue Mar 20, 2015 · 8 comments

Comments

Projects
None yet
2 participants
@amischler

In a similar fashion of the @Consumes and @Produces annotations of java.ws.rs, it could be great to be able to :

  • route a request more precisely to a specific controller method based on the content type of the request
  • specify the type of the result that a controller method is able to send to the client
@amischler

This comment has been minimized.

Show comment
Hide comment

@cescoffier cescoffier added this to the 0.8.1 milestone Mar 20, 2015

@cescoffier cescoffier added the feature label Mar 20, 2015

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 20, 2015

Member

We should not forget to write the VARY header in the response

Member

cescoffier commented Mar 20, 2015

We should not forget to write the VARY header in the response

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 22, 2015

Member

Another detail that matters, it should return UNSUPPORTED_MEDIA_TYPE when no methods can consume the given content (instead of NOT_FOUND)

Member

cescoffier commented Mar 22, 2015

Another detail that matters, it should return UNSUPPORTED_MEDIA_TYPE when no methods can consume the given content (instead of NOT_FOUND)

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 22, 2015

Member

Mime type range should be supported.
For reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Member

cescoffier commented Mar 22, 2015

Mime type range should be supported.
For reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 22, 2015

Member

After discussion, here are the planned format:

 @Route(method = HttpMethod.GET, uri = "/",
                    accepts = "text/plain",
                    produces = "application/html"
            )
public Result action() {
    // ...
}

It uses accepts and not consume, as accept is a HTTP concept, while consume is not.

accepts and produces can receive a list of mime type. accepts support wildcard such as text/*.

Member

cescoffier commented Mar 22, 2015

After discussion, here are the planned format:

 @Route(method = HttpMethod.GET, uri = "/",
                    accepts = "text/plain",
                    produces = "application/html"
            )
public Result action() {
    // ...
}

It uses accepts and not consume, as accept is a HTTP concept, while consume is not.

accepts and produces can receive a list of mime type. accepts support wildcard such as text/*.

@amischler

This comment has been minimized.

Show comment
Hide comment
@amischler

amischler Mar 23, 2015

It could also be great to be able to specify multiple values for accepts and produces, e.g.:

@Route(method = HttpMethod.GET, uri = "/",
                    accepts = "text/plain",
                    produces = "application/html,application/json"
            )
public Result action() {
    // ...
}

It could also be great to be able to specify multiple values for accepts and produces, e.g.:

@Route(method = HttpMethod.GET, uri = "/",
                    accepts = "text/plain",
                    produces = "application/html,application/json"
            )
public Result action() {
    // ...
}
@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 23, 2015

Member

yes it's done that way - both attributes can receive several values. Accepts accepts wildcard such as text/*, while produces does not.

Member

cescoffier commented Mar 23, 2015

yes it's done that way - both attributes can receive several values. Accepts accepts wildcard such as text/*, while produces does not.

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 23, 2015

Member

For information, I'm really close to get it done. Have to implement integration tests and update the documentation.

(was stuck on conflicts detection, but found an acceptable algorithm)

Member

cescoffier commented Mar 23, 2015

For information, I'm really close to get it done. Have to implement integration tests and update the documentation.

(was stuck on conflicts detection, but found an acceptable algorithm)

cescoffier added a commit that referenced this issue Mar 23, 2015

#456 - Update router API to support `accepts` and `produces` parameter
Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>

cescoffier added a commit that referenced this issue Mar 23, 2015

#456 - Implement new router API in the request router
Also add tests

Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>

cescoffier added a commit that referenced this issue Mar 23, 2015

#456 - Use new router API
Also update tests to mock the new method

Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>

cescoffier added a commit that referenced this issue Mar 23, 2015

#456 - Add new method in fake router
Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>

cescoffier added a commit that referenced this issue Mar 23, 2015

#456 - Add documentation about `produces` and `accepts`
Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>

@cescoffier cescoffier closed this Mar 23, 2015

cescoffier added a commit that referenced this issue Mar 24, 2015

#456 - Remove useless null check
Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>

cescoffier added a commit that referenced this issue Mar 24, 2015

#456 - Move documentation to another section
Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment