From: "Ted Jones" To: rareddy@redhat.com Cc: "Steven Hawkins" , "Ken Johnson" , "Barry Lafond" Sent: Tuesday, May 31, 2011 10:28:15 AM Subject: Re: Extension Properties for REST Ramesh... Let me give you a typical scenario... I have a VDB called books with 4 procedures: getBooks() Extended properties: URI=books REST-METHOD=GET PRODUCES=XML getBookByID() URI=books/{isbn} (this is a standard REST architecture design. IMO we need to allow for key values to be included in the URI) REST-METHOD=GET PRODUCES=XML insertBook() URI=books REST-METHOD=POST CONSUMES=XML PRODUCES=XML (this could be a success/fail xml document string). They may choose to return nothing. updateBook() URI=books/{isbn} REST-METHOD=PUT CONSUMES=XML PRODUCES=XML (this could be a success/fail xml document string). They may choose to return nothing. The required extended properties would be used to generate the following resource class used in a RESTEasy war: public class BookResource { public BookResource() { loadProperties(); } @POST @Consumes( "application/xml" ) @Produces( "application/xml" ) public String insertBook( InputStream is ) { parameterMap.clear(); parameterMap = getInputs(is); return teiidProvider.execute("insertBook", parameterMap); } @GET @Path( "{isbn}" ) @Produces( "application/xml" ) public String getBookByID( @PathParam( "isbn" ) String isbn ) { parameterMap.put("isbn", isbn); return teiidProvider.execute("getBookByID", parameterMap); } @GET @Produces( "application/xml" ) public String getBooks() { return teiidProvider.execute("getBooks", parameterMap); } @PUT @Path( "{isbn}" ) @Consumes( "application/xml" ) @Produces( "application/xml" ) public String updateBook( @PathParam( "isbn" ) String isbn, InputStream is ) { parameterMap.put("isbn", isbn); parameterMap = getInputs(is); return teiidProvider.execute("updateBook", parameterMap); } @DELETE @Path( "{isbn}" ) @Produces( "application/xml" ) public String deleteCustomer( @PathParam( "isbn" ) String isbn ) { parameterMap.put("isbn", isbn); return teiidProvider.execute("deleteCustomer", parameterMap); } protected Map getInputs( InputStream is ) { try { DocumentBuilder builder = DocumentBuilderFactory.newInstance().newDocumentBuilder(); Document doc = builder.parse(is); Element root = doc.getDocumentElement(); // input Map parameters = new LinkedHashMap(); if (!root.getNodeName().equals("input")) throw new WebApplicationException(Response.Status.BAD_REQUEST); NodeList nodes = root.getChildNodes(); for (int i = 0; i < nodes.getLength(); i++) { Element element = (Element)nodes.item(i); parameters.put(element.getNodeName(), element.getTextContent()); } return parameters; } catch (Exception e) { throw new WebApplicationException(e, Response.Status.BAD_REQUEST); } } private void loadProperties() { try { // Get the inputStream InputStream inputStream = getClass().getClassLoader().getResourceAsStream("teiidrest.properties"); //$NON-NLS-1$ properties = new Properties(); // load the inputStream using the Properties properties.load(inputStream); } catch (IOException e) { String msg = RestPlugin.Util.getString("TeiidWSProvider.1"); //$NON-NLS-1$ logger.logrb(Level.SEVERE, "TeiidWSProvider", "loadProperties", RestPlugin.PLUGIN_ID, msg, new Throwable(e)); //$NON-NLS-1$ //$NON-NLS-2$ throw new RuntimeException(e); } } } With regards to MIME type, this design does not preclude the user from specifying the return type. This is a client concern. That's a good point about wrapping the result using xmltojson(). This may allow us to claim JSON support as well. I will test that out once I get the basic generation working. ----- Original Message ----- From: "Ramesh Reddy" To: "Ted Jones" Cc: "Steven Hawkins" , "Ken Johnson" , "Barry Lafond" Sent: Tuesday, May 31, 2011 9:44:30 AM Subject: Re: Extension Properties for REST I am not sure I understand the usecase. Why a user sends some parameters through inputstream and some as scalar and some as XML. Too complicated. If the input is XML, there is only one parameter like document style IMO. If this is GET operation, then you need to come up with some standard way to pass the parameters, like http://foo.com/procedureName?p1=param1&p2=param2 where in /procedureName is the URI specified by the user p1=param1&p2=param2 is the something we define as to how to send the input if this is POST http://foo.com/procedureName where in /procedureName is the URI specified by the user if the inputs are scalar, you read them from RequestContext, if the input is XML, Clob, Blob then you use inputstream to read them As per the output, it is the MIME type defines what is the output form requested. Randall mentioned this earlier thread. The procedure always should either return a scalar or XML, based on the MIME type your REST framework should convert it to requested format. For this release, you should just stick to XML as out. If you want JSON too, then apply "xmlToJson" function on top of the procedure. Ramesh.. On Tue, 2011-05-31 at 10:29 -0400, Ted Jones wrote: > I considered that but if the URI contains one or more parameters like {id1}/{id2}/{id3} and the procedure accepts 10 parameters (7 of which will be passed in via some form of input stream), we would have to figure out which was which, count the number of parameters in the URI compared to the number of parameters in the procedure, etc. Also, moving forward, this would allow the user to specify if they want to consume/produce XML, JSON, text, HTML, ... which in regards to the REST input at least, the procedure metadata can't tell us. > > ----- Original Message ----- > From: "Ramesh Reddy" > To: "Ted Jones" > Cc: "Steven Hawkins" , "Ken Johnson" , "Barry Lafond" > Sent: Tuesday, May 31, 2011 9:11:17 AM > Subject: Re: Extension Properties for REST > > IMO, these if you need can be derived from looking at the metadata of > the procedure, no reason for user to explicitly define them. > > Ramesh.. > > On Tue, 2011-05-31 at 09:58 -0400, Ted Jones wrote: > > Upon further review, we will also need: > > > > CONSUMES - type of input stream (only XML for this release) > > PRODUCES - type of output (only XML for this release) > > > > Even though we will only process XML initially, I still need this information to know to generate consumes/produces annotations in the resource class as well as adding the return type and/or input stream parameter. > > > > Also, I will need a UI to allow for JNDI name. So, instead of auto-generating everything for this release, I will prompt for war name, JNDI name and war file location. I can re-use my UI from the war generation wizard, so it should not be too bad. Also, based on Fritz' email, we may have a larger window to get this in... so time isn't quite the issue it was as of last Friday. > > > > > > ----- Original Message ----- > > From: "Ramesh Reddy" > > To: "Ted Jones" , "Steven Hawkins" , "Ken Johnson" , "Barry Lafond" > > Sent: Friday, May 27, 2011 11:50:29 AM > > Subject: Extension Properties for REST > > > > Extended Properties required on the procedure for RESTful procedure > > invocation. If you think we need more please suggest. > > > > URI - relative URI of the procedure > > REST-METHOD - GET,POST,DELETE,PUT > > > > Thanks > > > > Ramesh.. > > > > > >