http://lmgtfy.com/?q=jersey+mailing+list+unsubscribe&l=1
:D
On Fri, Jun 10, 2016 at 2:28 PM, adam hardie <adamh137_at_gmail.com> wrote:
> hi please remove me from mail list i dont know how to remove myself
>
> On Fri, Jun 10, 2016 at 9:27 PM, Tony Zakula <tonyzakula_at_gmail.com> wrote:
>
>> I would use what works and what is best for you. Standards are great,
>> but we do not have to be purists in everything we do to get work done.
>> Jersey still runs on a servlet and you can easily tap that session if you
>> want to, nothing wrong with that. HTTP that REST is built on even supports
>> cookies for the session. What is wrong with mixing and matching a few
>> pieces to make building your app easy? Nothing. You can even support
>> stateless and state on the same API calls with Jersey to satisfy different
>> clients. Mobile apps may store state and web browsers do not. Offer both
>> if needed. Your app will still work even if you do not adhere to the
>> standard.
>>
>> In the end, build an app to fit your use case and that works well for
>> you.
>>
>>
>> On Fri, Jun 10, 2016 at 2:38 PM, Trenton D. Adams <
>> trenton.d.adams_at_gmail.com> wrote:
>>
>>> Your descriptions of what REST is what I would like it to be, but it
>>> isn't that, accrording to most everything I've read on it. If you're
>>> storing state, you're not using REST. The use of REST precludes maintaing
>>> state server side. I'm tempted to use JAX-RS regardless, and just not use
>>> the statelessness part.
>>>
>>> https://en.wikipedia.org/wiki/Representational_state_transfer#Stateless
>>> Stateless
>>> See also: Stateless protocol
>>> The client–server communication is further constrained by no client
>>> context being stored on the server between requests. Each request from any
>>> client contains all the information necessary to service the request, and
>>> session state is held in the client. The session state can be transferred
>>> by the server to another service such as a database to maintain a
>>> persistent state for a period and allow authentication. The client begins
>>> sending requests when it is ready to make the transition to a new state.
>>> While one or more requests are outstanding, the client is considered to be
>>> in transition. The representation of each application state contains links
>>> that may be used the next time the client chooses to initiate a new
>>> state-transition.[12]
>>>
>>>
>>> On Fri, Jun 10, 2016 at 1:04 PM, Robert Gacki <
>>> robert.gacki_at_contenttrace.org> wrote:
>>>
>>>> Hi Trenton,
>>>>
>>>> I think, you misunderstand what REST is. REST is about how a server and
>>>> a client interacts to transfer state. The transport itself is stateless
>>>> ("dumb pipes"). It is an architectural style. The notion of state is
>>>> something the client and server have to implement themself. What REST
>>>> describes is nothing else what HTTP specifies, but is not limited to
>>>> HTTP (think of mail). In fact, Roy Fielding just took HTTP as an
>>>> example for REST in his dissertation.
>>>>
>>>> OSI Layer
>>>> ----------------------------------------------------
>>>> | Your server and/or client application | L |
>>>> ---------------------------------------------- a |
>>>> | REST as architectural style | y 7 |
>>>> ---------------------------------------------- e |
>>>> | HTTP|MAIL|<other req / res based protocols>| r |
>>>> ----------------------------------------------------
>>>> Layer 6 and below
>>>>
>>>> JAX RS is only about modelling REST principles and Jersey provides the
>>>> implementation. That does not include state management. So you should
>>>> see JAX RS as the protocol toolset ("dumb pipes") to build
>>>> applications. What you call stateful is application state and that is
>>>> always application / implementation specific. For example, the notion
>>>> of a session is purely application specific.
>>>>
>>>> So Jersey, at its core, does not provide you with components to build
>>>> things like a wizard. But it provides you the ability to build or use
>>>> existing components, like JSR 371 and its implementations.
>>>>
>>>> To your wizard example: You can solve wizards with different methods.
>>>> You described one solution, where the server does not store results of
>>>> previous wizard steps. Each solution has advantages and disadvantages.
>>>> But all solutions have something in common: they are application
>>>> specific. If you use HTTP as a communication protocol, you can use REST
>>>> principles to have a well-defined architectural style. But you still
>>>> need to figure out how to maintain state between a request and
>>>> response.
>>>>
>>>> An important part of REST is Hypermedia. For HTTP, this is just
>>>> payload. For an application built by REST principles, it is the state
>>>> that is transfered. And that state should include all information
>>>> necessary for server or client to support continous interactions. If
>>>> you use your browser and surf around, clicking on links or signing in
>>>> into your Google account, you are doing exactly what REST proposes for
>>>> all other media types - not just HTML.
>>>>
>>>> So your wizard solution is based on HTML (a representation) and is
>>>> constraint by the HTML specification and how browsers behave. Thus, you
>>>> may lose form field values when you use the browser's back button. But
>>>> you can do three things to counter that without storing state server-
>>>> side (outside request-response bounds): 1) You can provide a back
>>>> button inside the form that just submits to the server - the server
>>>> renders the previous page with the values from the hidden fields. 2) In
>>>> modern browsers, with Javascript enabled, you can store the state
>>>> client side and restore it when the user goes back. 3) SPAs mostly
>>>> avoid the problem by avoiding round-trips to the server, with the
>>>> disadvantage of cloning lots of server-side logic for the client
>>>> (validation, business logic).
>>>>
>>>> Robert
>>>>
>>>>
>>>> Am Freitag, den 10.06.2016, 12:11 -0600 schrieb Trenton D. Adams:
>>>> > Thanks for the responses guys. I'm thinking more along the lines of
>>>> > JAX-RS implementations, such as Jersey, providing a template based
>>>> > approach, where the result can be served by JSP. Technically, that's
>>>> > almost useless when doing it statelessly, unless your service is
>>>> > intended to return HTML to a client program, or you intend to violate
>>>> > the statelessness of REST. Cause like you say, writing BBAs, is
>>>> > actually quite tough without some nice statefulness.
>>>> >
>>>> > JSR 371 will be coming out too. Are they still expecting stateless?
>>>> > Cause it suddenly becomes less useful. Maintaining all the state in
>>>> > the browser's store is a lot of extra work, and just a plain weird
>>>> > way of dealing with it.
>>>> >
>>>> > On Fri, Jun 10, 2016 at 10:07 AM, <lenny_at_flowlogix.com> wrote:
>>>> > > Trenton, I feel your pain.
>>>> > > In all honesty, the technology architecture didn’t change all that
>>>> > > much in the last 10 years.
>>>> > > Don’t get caught up in the Rest/Microservices hype too much.
>>>> > > For BBAs (boring business apps) which I believe that you are
>>>> > > dealing with (and I also like developing),
>>>> > > it makes very little sense migrating to Rest-based architecture.
>>>> > > Concentrate on cleaning, refactoring, modularizing your code, using
>>>> > > the latest iterations of Java EE specs that you are already using.
>>>> > >
>>>> > > So, why all the hype?
>>>> > > Current Rest “state-of-the-art” today is actually in it’s very
>>>> > > infancy. It makes sense for some applications to do it though, but
>>>> > > not for BBAs.
>>>> > > What apps does the Stateless Rest APIs make sense for?
>>>> > > - Multiple clients written separately by different teams (i.e.
>>>> > > native iOS, native Android, native JavaScript)
>>>> > > - APIs that other companies use in different (non-Java) languages
>>>> > > - There are some other use cases also, but the above are the major
>>>> > > ones
>>>> > >
>>>> > > What’s the negative impact of Rest services today, as it relates to
>>>> > > Java client and server development?
>>>> > > - Massive violation of DRY principle, as it’s really meant for
>>>> > > client and server to be written in different languages,
>>>> > > i.e. client in JavaScript/iOS/Android and server in Java
>>>> > > - Data models are duplicated both in Java (on the server) and on
>>>> > > the client (JS/iOS/Android)
>>>> > > - Validation is duplicated on the client and server
>>>> > > - Some business logic may need to be duplicated in the client and
>>>> > > server
>>>> > >
>>>> > > The above negatives are something that are not solved by the
>>>> > > industry quite yet, and for BBAs, (IMHO) is not worth the effort.
>>>> > >
>>>> > > As far as answering your specific question, in “pure” Rest API, All
>>>> > > state is indeed handled by the client, including authentication.
>>>> > > Authentication is usually handled by “bearer token” paradigm, is
>>>> > > sent with every request to the server, and thus re-authenticated by
>>>>
>>>> > > the server every time.
>>>> > > Yes, it sounds (and is) a bit less efficient on per-request basis
>>>> > > (throughput per instance), but does (horizontally) scale better to
>>>> > > millions of users.
>>>> > >
>>>> > >
>>>> > > > On Jun 9, 2016, at 4:40 PM, Trenton D. Adams <trenton.d.adams_at_gma
>>>> > > > il.com> 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_web
>>>> > > > > storage.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.o
>>>> > > > > > rg> 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-applic
>>>> > > > > > > > ations-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.
>>>> > > > > > > >
>>>> > > > > > >
>>>> > > > >
>>>> > >
>>>>
>>>
>>>
>>
>