org.mattressframework.api.annotations.HttpEntity Maven / Gradle / Ivy
Show all versions of mattress-api Show documentation
/*
* Copyright 2007-2008, Josh Devins.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.mattressframework.api.annotations;
import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import org.mattressframework.api.HttpEntityReader;
import org.mattressframework.api.Provider;
/**
* Annotation marking that a parameter to a method annotated with
* {@link HttpResourceMethod} is the request entity body. It will have been
* deserialized by an entity {@link Provider}.
*
*
* This annotation does not exist in JSR 311 for some reason. Instead it assumes
* that the one and only one unannotated parameter is the request entity body. I
* prefer to not assume. I also want to be able to constrain what kind of
* content type/media type that this entity can be created from.
*
*
* @author Josh Devins ([email protected])
*/
@Documented
@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
public @interface HttpEntity {
/**
* Constrains what media types the entity can be. The framework will only
* look for {@link HttpEntityReader}s that support these media types.
*
*
* This is useful for providing some sort of polymorphism in REST. That is,
* if two resource methods have the same path, but differ by the
* {@link HttpEntity} media type they accept. If one resource method takes
* anything and one takes "text/plain", then you can use this to define
* which Java method will handle which request, even though they are
* addressed to the same path.
*
*
*
* For example, in the following code snippet, a request with Content-Type
* "text/xml" or "text/json" will be handled by the method "createSomething"
* and will presumably be deserialized by XStream or something of the sort.
* A request with Content-Type "text/plain" will be handled by the method
* "createSomethingFromString" which simply takes the entity body as a
* String.
*
* Request
* Path: /rest/something
* Content-Type: text/json
*
* Methods:
*
*
* @Path("something")
* public void createSomething(@HttpEntity Something something) {
* ...
* }
*
* @Path("something")
* public void createSomethingFromString(@HttpEntity("text/plain") String something) {
* ...
* }
*
*
*
*
* An empty array or not setting this property at all implies that any
* supported enity type can be sent.
*
*
*
* Default: An empty array.
*
*/
String[] value() default {};
}