On Tue, Mar 27, 2018 at 4:49 AM, <peter.sk...@ooom.at> wrote: > Hi, >
Hello! > tapestry 5.4 made with the requireJS integration a great step towards > supporting any > of the JS frameworks out there. Supporting only a single one of them would > be a step > back. > Indeed. This doesn't prevent having separate projects/JARs for making it easier to use one specific JS framework, though. > Using tapestry on the server side of dynamic client applications is > effective as it > possible to initialize the pages in a context specific way and to provide > the RESP API > for them, everything smoothly integrated with java side components and > greatly > reusable. This is all working very well in 5.4. > Even not implementing JAX-RS, Tapestry can be used for lots of REST endpoint scenarios. The ones not covered yet, at least not in an explicit, easy way, are ones involving non-GET operations. I suspect (I haven't looked at this yet) that it wouldn't be had to add this to Tapestry, inside its core or even as a separate project/JAR. We could also have Tapestry implement at least a subset of JAX-RS. I guess the starting point would be supporting @GET, @PUT, @POST, @DELETE, @HEAD, @Produces and @Consumes. The @*Param could probably be easily implemented by copying and adapting the code of @RequestParameter. Data transformations would be delegated to TypeCoercer. > Very helpful would be to provide the REST API description endpoints out of > the box – > something of the art of swagger. What would be the most effective design > for it? > If we had Tapestry implement a subset of JAX-RS, we would probably have enough information in class transformations in order to feed endpoint information to Swagger (which I don't know yet) or something similar.
