Re: [Resteasy-developers] Programatic endpoints in RESTEasy

[Bill B. <bb...@re...>]

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 [1].
>
> 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 [2] 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.

> Thanks,
> Jay
>
> [1] https://gist.github.com/3938238
> [2] 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 
queue.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com