Please don't take any of my comments here personally. Everybody CC'd on
this email thread is smart and dedicated. I think I came across as too
combatative with them. Apologies. But, I'm trying to get them to
convince me this is a good idea because it will need fundamental changes
to Resteasy. I honestly need to do this work because in the end,
myself, Ron, and Wei need to maintain and support it.
Also, quite honestly, there is other work I'd much rather focus on, and
have wnated to focus on for a long long time. Specifically security.
Not only that, but I've contracted with O'Reilly to update my book. So,
Doug, Dan, need to do some serious defending of why they want to do this.
FYI: I"m not convinced that what they want to do is a good idea. Why
wouldn't you just have a mobile client make HTTP invocations directly to
a JAX-RS service?
On 10/24/2012 5:02 PM, Jay Balunas wrote:
> Hi Bill,
> I wanted to talk about the request Doug and Dan put in around
> programatic endpoints. I think they did a great job of defining the
> initial feature set in the gist .
> There are a few compelling reasons to have this support that might make
> this worth reconsidering:
> 1) As part of a future dynamic Backend as a Service (BaaS) being able to
> programmatically create and update endpoints would be a great feature.
> 1.5) Take a look at Kinvey, or Parse for examples of this functionality.
I don't understand why you would want to programmatically create or
modify HTTP request -> Java method mappings. Seems like a bad idea to
me. JAx-RS is very sensative to the structure of a URL. I can't see
anybody ever wanting to dynamically change that a method parameter is
mapped from a path segment to, let's say a query parameter.
I'm not a big fan of hiding remote invocations and blurring the line
between client and server. When I see descriptions like "
> 2) As part of a light MVC with central routing, programatic endpoints
> let us define these in one place.
I disagree with this approach. Use an MVC framework if you want to do
MVC, why do you need JAX-RS? Why do you even need MVC anymore now that
we have rich clients? Don't you realize REST is mainly a stateless
architecture. Now that rich clients can hold state, we don't need this
MVC nonsense anymore.
I know Jersey has some Model-View support, but, I'm not convinced in the
slightest that this belongs in a framework targeted to RESTful
applications. If work can be done to integrate Resteasy as-is to an
existing MVC framework, that's cool, like we did with Seam and Spring
MVC. But don't ask me to rearchitect resteasy to do this.
Futhermore, why don't you just use Errai and their WebSocket-based
protocol? Then you can do all the RPC you want and not follow this
silly idea of REST.
> 3) One feature I've been thinking about is dynamic endpoints based on
> client library requests
> 3.1) Client lib request entity "foo" but it does not exist, "/foo" is
> created with supporting methods
> 3.2) This would not be type-safe, but would be great in a JSON/dynamic world
I don't understand. JAX-RS is a mapping from HTTP request to specific
Java methods and Java types. It is not a generic Servlet-like API.
> Also back in May when this was discussed before on the resteasy mailing
> list  you had mentioned about Doug driving this after 3.0.Alpha.
> This is what Doug and Dan want to help with.
That was a nice way of me saying I don't find this feature important.
> So, all I'm asking is that was that talk about this a little more, see
> if there is a less invasive way of doing these changes, especially since
> Dan will be able to help and/or prototype some of this.
Yup let's talk, as long as you don't take offense to me being aggressive
here. Please please, don't take *ANY* of this personally. I've been on
the record for a long time internally at Red Hat as not being a fan of
any of these web frameworks.
>  https://gist.github.com/3938238
>  http://sourceforge.net/mailarchive/message.php?msg_id=29626985
I'll re-read this stuff tomorrow so I can better understand where you
guys are coming from.
The only compelling argument I've seen so far is that it could possibly
be used to support other languages like Python, Ruby, etc. that run in
the JVM. Interesting, but not reason enough to bump it up on our work
JBoss, a division of Red Hat