![\"rest-validation\"](\"http:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2013\/08\/rest-validation.png\")
<\/a><\/p>\nImplementing REST Resources<\/h4>\n
For a Java shop like us, it makes sense to use JAX-B<\/a> to generate JavaBean<\/a> classes from an XML Schema. Working with XML (and JSON) payloads using JAX-B is very easy in a JAX-RS<\/a> environment like Jersey<\/a>:<\/p>\n (Note that you shouldn\u2019t use these generic media types, but that\u2019s a discussion for another day.)<\/p>\n The remainder of this post assumes JAX-B, but its main point is valid for other technologies as well. Whatever you do, please don\u2019t use Let\u2019s suppose the order\u2019s We can do that with input validation<\/a>, one of the most important tools in the AppSec<\/a> toolkit. Let\u2019s look at some ways to implement it.<\/p>\n Validating individual properties will probably work fine, but things get hairy when we want to validate relations between properties. For maximum flexibility, we\u2019d like to use Java to express constraints.<\/p>\n More importantly, schema validation is generally not a good idea in a REST service<\/strong>.<\/p>\n A major goal of REST is to decouple client and server<\/a> so that they can evolve separately.<\/p>\n If we validate against a schema, then a new client that sends a new property would break against an old server that doesn\u2019t understand the new property. It\u2019s usually better to silently ignore properties you don\u2019t understand.<\/p>\n JAX-B does this right, and also the other way around: properties that are not sent by an old client end up as Jersey supports Bean Validation by adding the There is an unofficial Maven plugin to add Bean Validation annotations<\/a> to the JAX-B generated classes, but I\u2019d rather use something better supported and that works with Gradle<\/a>.<\/p>\n So let\u2019s turn things around. We\u2019ll handcraft our JavaBean and generate the XML Schema from the bean<\/a> for documentation:<\/p>\n Any attempt to Now suppose we want to allow clients to change their pending orders. We\u2019d use We need to add the We need a public no-arg constructor for JAX-B to be able to unmarshall the payload into a JavaBean and another constructor that takes a We can fix that by mapping validation exceptions onto At first sight, proponents of Domain-Driven Design<\/a> (DDD) might like the idea of creating the But the DDD deals with domain concepts, while REST deals with representations<\/em> of those concepts.<\/strong> Domain concepts are discovered, but representations are designed<\/strong> and are subject to all kinds of trade-offs.<\/p>\n For instance, a collection REST resource may use paging to prevent sending too much data over the wire. Another REST resource may combine several domain concepts to make the client-server protocol less chatty.<\/p>\n A REST resource may even have no corresponding domain concept at all. For example, a When designing REST resources, on the other hand, one needs to make trade-offs to meet non-functional requirements like performance, scalability, and evolvability.<\/p>\n That\u2019s why I don\u2019t think an approach like RESTful Objects<\/a> will work. (For similar reasons, I don\u2019t believe in Naked Objects<\/a> for the UI.)<\/p>\n Adding validation to the JavaBeans that are our resource representations means that those beans now have two reasons to change, which is a clear violation of the Single Responsibility Principle<\/a>.<\/p>\n We get a much cleaner architecture<\/a> when we use JAX-B JavaBeans only for our REST representations and create separate domain objects that handle validation.<\/p>\n Putting validation in domain objects is what Dan Bergh Johnsson<\/a> refers to as Domain-Driven Security<\/a>.<\/p>\n At first it may seem overkill to create a whole new class to hold a single integer, but I urge you to give it a try. You may find that getting rid of primitive obsession<\/a> provides value even beyond validation. How do you handle input validation in your RESTful services? What do you think of Domain-Driven Security? Please leave a comment. How To Implement Input Validation For REST\u00a0resources The SaaS platform I\u2019m working on has a RESTful interface that accepts XML payloads. Implementing REST Resources For a Java shop like us, it makes sense to use JAX-B to generate JavaBean classes from an XML Schema. Working with XML (and JSON) payloads using JAX-B is very easy …<\/p>\n","protected":false},"author":280,"featured_media":112,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[54],"class_list":["post-16683","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-java","tag-restful-web-services"],"yoast_head":"\n@Path(\"orders\")\r\npublic class OrdersResource {\r\n @POST\r\n @Consumes({ \"application\/xml\", \"application\/json\" })\r\n public void place(Order order) {\r\n \/\/ Jersey marshalls the XML payload into the Order \r\n \/\/ JavaBean, allowing us to write type-safe code \r\n \/\/ using Order's getters and setters.\r\n int quantity = order.getQuantity();\r\n \/\/ ...\r\n }\r\n}<\/pre>\nXMLDecoder<\/code><\/a>, since that is open to a host of vulnerabilities<\/a>.<\/p>\nSecuring REST Resources<\/h4>\n
quantity<\/code> is used for billing, and we want to prevent people from stealing our money by entering a negative amount<\/a>.<\/p>\nInput Validation With XML Schema<\/h4>\n
<\/a>We could rely on XML Schema for validation<\/a>, but XML Schema can only validate so much.<\/p>\nnull<\/code>. Consequently, the new server must be careful to handle null<\/code> values properly.<\/p>\nInput Validation With Bean Validation<\/h4>\n
<\/a>If we can\u2019t use schema validation, then what about using JSR 303 Bean Validation<\/a>?jersey-bean-validation<\/code><\/a> jar to your classpath.<\/p>\n@XmlRootElement(name = \"order\")\r\npublic class Order {\r\n @XmlElement\r\n @Min(1)\r\n public int quantity;\r\n}<\/pre>\n@Path(\"orders\")\r\npublic class OrdersResource {\r\n @POST\r\n @Consumes({ \"application\/xml\", \"application\/json\" })\r\n public void place(@Valid Order order) {\r\n \/\/ Jersey recognizes the @Valid annotation and\r\n \/\/ returns 400 when the JavaBean is not valid\r\n }\r\n}<\/pre>\nPOST<\/code> an order with a non-positive quantity will now give a 400 Bad Request<\/code> status.<\/p>\nPATCH<\/code> or PUT<\/code> to update individual order properties, like quantity:<\/p>\n@Path(\"orders\")\r\npublic class OrdersResource {\r\n @Path(\"{id}\")\r\n @PUT\r\n @Consumes(\"application\/x-www-form-urlencoded\")\r\n public Order update(@PathParam(\"id\") String id, \r\n @Min(1) @FormParam(\"quantity\") int quantity) {\r\n \/\/ ...\r\n }\r\n}<\/pre>\n@Min<\/code> annotation here too, which is duplication. To make this DRY<\/a>, we can turn quantity<\/code> into a class that is responsible for validation:<\/p>\n@Path(\"orders\")\r\npublic class OrdersResource {\r\n @Path(\"{id}\")\r\n @PUT\r\n @Consumes(\"application\/x-www-form-urlencoded\")\r\n public Order update(@PathParam(\"id\") String id, \r\n @FormParam(\"quantity\")\r\n Quantity quantity) {\r\n \/\/ ...\r\n }\r\n}<\/pre>\n@XmlRootElement(name = \"order\")\r\npublic class Order {\r\n @XmlElement\r\n public Quantity quantity;\r\n}<\/pre>\npublic class Quantity {\r\n private int value;\r\n\r\n public Quantity() { }\r\n\r\n public Quantity(String value) {\r\n try {\r\n setValue(Integer.parseInt(value));\r\n } catch (ValidationException e) {\r\n throw new IllegalArgumentException(e);\r\n }\r\n }\r\n\r\n public int getValue() {\r\n return value;\r\n }\r\n\r\n @XmlValue\r\n public void setValue(int value) \r\n throws ValidationException {\r\n if (value < 1) {\r\n throw new ValidationException(\r\n \"Quantity value must be positive, but is: \" \r\n + value);\r\n }\r\n this.value = value;\r\n }\r\n}<\/pre>\nString<\/code><\/a> for the @FormParam<\/code> to work.<\/p>\nsetValue()<\/code> throws javax.xml.bind.ValidationException<\/code> so that JAX-B will stop unmarshalling. However, Jersey returns a 500 Internal Server Error<\/code> when it sees an exception.<\/p>\n400<\/code> status codes using an exception mapper<\/a>. While we\u2019re at it, let\u2019s do the same for IllegalArgumentException<\/code>:<\/p>\n@Provider\r\npublic class DefaultExceptionMapper \r\n implements ExceptionMapper<Throwable> {\r\n\r\n @Override\r\n public Response toResponse(Throwable exception) {\r\n Throwable badRequestException \r\n = getBadRequestException(exception);\r\n if (badRequestException != null) {\r\n return Response.status(Status.BAD_REQUEST)\r\n .entity(badRequestException.getMessage())\r\n .build();\r\n }\r\n if (exception instanceof WebApplicationException) {\r\n return ((WebApplicationException)exception)\r\n .getResponse();\r\n }\r\n return Response.serverError()\r\n .entity(exception.getMessage())\r\n .build();\r\n }\r\n\r\n private Throwable getBadRequestException(\r\n Throwable exception) {\r\n if (exception instanceof ValidationException) {\r\n return exception;\r\n }\r\n Throwable cause = exception.getCause();\r\n if (cause != null && cause != exception) {\r\n Throwable result = getBadRequestException(cause);\r\n if (result != null) {\r\n return result;\r\n }\r\n }\r\n if (exception instanceof IllegalArgumentException) {\r\n return exception;\r\n }\r\n if (exception instanceof BadRequestException) {\r\n return exception;\r\n }\r\n return null;\r\n }\r\n\r\n}<\/pre>\nInput Validation By Domain Objects<\/h4>\n
<\/a>Even though the approach outlined above will work quite well for many applications, it is fundamentally flawed.<\/p>\nQuantity<\/code> class.<\/p>\nOrder<\/code> and Quantity<\/code> classes do not model domain concepts; they model REST representations. This distinction may be subtle, but it is important.<\/p>\nPOST<\/code> may return 202 Accepted<\/code><\/a> and point to a REST resource that represents the progress of an asynchronous transaction.<\/p>\n<\/a><\/a>Domain objects need to capture the ubiquitous language<\/a> as closely as possible, and must be free from trade-offs to make the functionality work.<\/p>\n<\/a>In this approach, primitive types are replaced with value objects. (Some people even argue against using any String<\/code>s<\/a> at all.)<\/p>\n
\n <\/p>\nWhat do you think?<\/h4>\n
\n <\/p>\n