Yes, the idea of scalability. As far as serving our users, we don't even
need scale-able. The only time we need scalability, is when we're
concerned with availability. And then, you only need 2-3 server instances
per service.
And yes, I can see it being difficult to design the rest service well.
There's a whole heck of a lot to thinking involved. Everything from
properly using HTTP, to picking uniform paths and what not. It would
require some thought, and unfortunately, a lot of developers would rather
just start writing code.
On Thu, Jun 9, 2016 at 7:11 PM, cowwoc <cowwoc_at_bbs.darktech.org> wrote:
> 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_webstorage.asp>
>> http://www.w3schools.com/html/html5_webstorage.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>
>> 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-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions>
>>> http://stackoverflow.com/questions/3105296/if-rest-applications-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.
>>>
>>>
>>>
>>
>>
>
>