Hi,
JAX-RS is a specification, not an implementation. JAX-RS defines how a
Java application can provide endpoints that follow REST principles. And
I don't see any big flaws in the specification. If it had big flaws, it
would have never been accepted as a JSR and never found its way into
Java EE.
Well, there are some things that can be improved (e.g. features for
navigation and linking). But that could easily lead to overengineering
of that specification. So its a good thing that its kept at a basic
level. And there are lots of libraries that extend Jersey / RestEasy /
* to provide more sugar.
You also said that REST is for computers, not humans. Sorry, but that
is just wrong. REST describes the basic principles of how the web
works. It was created at a time, where HTML clients were the common
kind of client to use HTTP. Fielding just explained that HTTP allows
other kinds of clients. This includes clients for humans and for
automation.
Robert
Am Donnerstag, den 09.06.2016, 21:11 -0400 schrieb cowwoc:
> JAX-RS != REST. It is one possible implementation of it and it has
> its flaws.
>
> Having worked with REST heavily over the past couple of years I would
> say that it is always a lot more work than you'd expect up-front for
> the server implementer but that it is actually a pleasure to use from
> the client perspective. Of course, this assumes that your REST API is
> well-designed, which is actually quite difficult to do.
>
> The main advantages of REST, as I understand it, is that it is far
> more scalable and technology-agnostic than the alternatives.
>
> Most people don't need either of those things (how many of you are
> building the next Facebook? Trust me, you're not) but it's a nice
> goal to strive for.
>
> Gili
>
> On 2016-06-09 5:40 PM, Trenton D. Adams wrote:
> > One thing I didn't mention, is that I'm considering updating one of
> > our enterprise apps to more modern technologies, where it actually
> > saves effort. It is currently based on RMI, with a custom web
> > front-end/mvc framework based on a the command pattern. So, I'm
> > trying to determine whether we should do EJB or JAX-RS for the
> > back-end, and possibly JAX-RS for the front end. One of the issues
> > is that EJB is almost a drop in replacement for RMI. It would
> > require significant more effort to switch to JAX-RS.
> >
> > When the back end is stateless, it's simply pushing the complexity
> > to the client. It is now the client that must do all the work to
> > know what it needs to send; i.e. it keeps it's own state. For the
> > back end, that's HIGHLY scale-able technology wise, but has other
> > drawbacks. With a stateful back-end, you just set the firstname,
> > lastname, birthdate, etc, and pass around a reference to the back-
> > end object, such as with EJB. Neither the front end nor the back
> > end have to maintain much state, programmatically speaking; it's
> > the service that does that (EJB for example). This saves developer
> > time, does it not?
> >
> > It seems that using the html5 stuff would be a pain in the butt.
> > Mainly because html5's storage system can't store a javascript
> > object even, so you can't even abstract your data storage. Plus,
> > we'd end up not supporting people with older machines/browsers.
> > And then, if you have a series of web pages that a person is going
> > through, you'd have to write code to grab all of that, and pass it
> > to the server.
> >
> > So, should I not use JAX-RS if I'm wanting to maintain state? I
> > mean it kind of goes against the "ST" in REST. Nothing actually
> > prevents you from maintaining state though.
> >
> > I've read some articles where people say you shouldn't even be
> > maintaining state of authentication. That I don't agree with,
> > because some services don't even have access to the user's
> > credentials. So at some point, someone is going to have to
> > maintain state. So, you could either not use JAX-RS, or use it and
> > maintain state while doing so, but essentially violate it's
> > principles.
> >
> > Also, doesn't statelessness become very complex when you have
> > larger enterprise applications?
> >
> > I see a lot of benefits of JAX-RS, and a lot of drawbacks. Am I
> > missing something?
> >
> > On Wed, Jun 8, 2016 at 5:46 PM, cowwoc <cowwoc_at_bbs.darktech.org>
> > wrote:
> > > Define "application logic".
> > >
> > > In the case you mentioned below (storing the user's last name
> > > somewhere) I would favor using localStorage and sessionStore to
> > > store this information: http://www.w3schools.com/html/html5_webst
> > > orage.asp
> > > The client would read the information from the local store and
> > > use it to make AJAX calls.
> > >
> > > I misspoke earlier when I talked about Cookies. These are
> > > typically used to reference to a server-side state that is
> > > present across all calls. If some REST calls need one piece of
> > > information and others need another, I would pull them from the
> > > local/sessionStore and pass them to the AJAX calls as needed.
> > >
> > > Gili
> > >
> > >
> > > On 2016-06-08 7:40 PM, Trenton D. Adams wrote:
> > > > So are you saying push all the application logic to the
> > > > browser, using javascript? Are cookies really intended to
> > > > store a whole bunch of user data?
> > > >
> > > > I know with HTML5, you can use
> > > > sessionStorage.setItem("lastname", "last name"). But, I don't
> > > > think moving most application logic into a browser is very
> > > > maintainable, maybe I'm wrong though.
> > > >
> > > > On Wed, Jun 8, 2016 at 5:29 PM, cowwoc <cowwoc_at_bbs.darktech.org
> > > > > wrote:
> > > > > Without commenting on the specifics of Jersey, I agree: REST
> > > > > is for computers, not humans.
> > > > >
> > > > > I typically expose REST APIs for computers and use cookies to
> > > > > maintain browser sessions. The browser can then read stateful
> > > > > information from the Cookie and serve it to stateless REST
> > > > > APIs. Not all clients are web-browsers, so your REST API
> > > > > should be designed around non-browsers.
> > > > >
> > > > > Gili
> > > > >
> > > > >
> > > > > On 2016-06-08 5:58 PM, Trenton D. Adams wrote:
> > > > > > Good day,
> > > > > >
> > > > > > I'm a bit confused. I actually have two separate
> > > > > > questions. I understand that REST is supposed to be done
> > > > > > in a stateless
> > > > > > way. For regular web
> > > > > > services that's easy. I mean it really shifts
> > > > > > a lot of the work to
> > > > > > the client, where it seems to be more difficult to deal
> > > > > > with, but as far as the server goes, it's simple.
> > > > > >
> > > > > > However, how is it even possible to use jersey templates
> > > > > > without state (sessions), in a reasonable way? The browser
> > > > > > isn't going to maintain the state. It seems that one would
> > > > > > need to make sure each and every page puts hidden inputs
> > > > > > from the previous form, in the html output, so that it is
> > > > > > re-submitted with the new request. That would be a lot of
> > > > > > work. If the user presses the back button, all that state
> > > > > > vanishes, and the user must re-enter any screens they go
> > > > > > forward to again. This doesn't make for a very good user
> > > > > > experience.
> > > > > >
> > > > > > Can someone explain to me how the use of JAX-RS as an MVC
> > > > > > framework is even possible in a reasonable way, while being
> > > > > > stateless?
> > > > > >
> > > > > > Then, can someone explain to me how statelessness in a
> > > > > > back-end REST web service, promotes good code design, where
> > > > > > user interaction is a necessity? It seems to me that the
> > > > > > client would then need to maintain all the state, thereby
> > > > > > tightly coupling all the data points between the different
> > > > > > controllers on the client. Something like EJB allows you
> > > > > > to pass around the stateful pointer, and you simply add
> > > > > > data as you go.
> > > > > >
> > > > > > After reading this stack exchange post, it's sounding like
> > > > > > everyone thinks that REST is NOT for users, but for
> > > > > > services only.
> > > > > > http://stackoverflow.com/questions/3105296/if-rest-applicat
> > > > > > ions-are-supposed-to-be-stateless-how-do-you-manage-
> > > > > > sessions
> > > > > >
> > > > > > I understand that it's more scalable, as the server always
> > > > > > knows exactly what you want, because you're telling it
> > > > > > every time. But it seems like that would come with a lot
> > > > > > more boilerplate coding.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > >
> > >