In my way of thinking, "REST support" can have at least two different implementations.
a) Great support for HTTP:
- synchronous request/reply
- important verbs (e.g. GET, PUT, POST, DELETE)
- access to the entire URI & query string, ease of access in an action to the URI, in some cases to make routing decisions
- ability to change the content-type of the response
- ability to return declared HTTP response codes
- multiple services per port
- support for reading and setting the HTTP headers in an action
- support for marshalling the response data as XML or JSON, based on the HTTP Accept header
Examples:
GET http://localhost:8080/orders/10 - fetch me order id 10
PUT http://locahost:8080/orders/10 - insert with order id 10
POST http://locahost:8080/orders - insert order, return a
Status 201 Created
Location: http://localhost:8080/orders/1235
GET http://localhost:8080/orders/10/orderlines - fetch me the order line-items from order id 10
b) Inclusion of and support for a JAX-RS implementation like RESTEasy. This could work like the older 181 annotated JAX-WS endpoint with SOAPProcessor action. I'm not sure how to map it to the EBWS feature.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228770#4228770
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228770
"timfox" wrote : What about ODF and PDF?
OpenOffice saves ODF documents in a zip file, so we won't be able to resolve conflicts. Ditto for PDF (it is a binary format)
If we got the OOo way, the best approach would be to save in ODF (that's the best format for OOo), make sure we communicate on document changes to avoid svn conflicts.
And we'd have to generate the HTML and PDF documents manually when doing a release.
Is that ok for everybody?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228761#4228761
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228761