Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] RESTful implementations

Expand Messages
  • Tim Williams
    ... I don t know, it seems like you re comparing apples and oranges here. You can use JAX-RS as a tool to build an origin server that is both simple and
    Message 1 of 30 , Nov 8, 2010
    • 0 Attachment
      On Mon, Nov 8, 2010 at 3:45 PM, Eric J. Bowman <eric@...> wrote:
      > Tim Williams wrote:
      >>
      >> >
      >> > None!  If you're heavily invested in a legacy Java system, then I'm
      >> > sure such frameworks have their uses.  If you're in a position
      >> > *not* to use JAX-RS, then by all means, don't!  My reaction to
      >> > JAX-RS is, "What the hell are you folks even *talking* about?!?"
      >> >  Surely not REST.
      >>
      >> Re: JAX-RS, I'll reluctantly bite, why do you have that reaction?
      >>
      >
      > See REST 2.3.3 and 2.3.4, then point me to an actual RESTful service
      > built around JAX-RS which exhibits any of these characteristics.  For
      > example, configurability seems to be a matter of re-coding the system.
      > I can't follow any JAX-RS discussions, as they use terminology that I'm
      > unfamiliar with (injection, marshalling, controller, persistence,
      > repository and more) in the REST context, while studiously avoiding any
      > use of terms like "representation" or "hypertext constraint".  Simply
      > too much complexity for my tastes, I understand REST just fine without
      > all the enterprisey lingo (or Java).

      I don't know, it seems like you're comparing apples and oranges here.
      You can use JAX-RS as a tool to build an origin server that is both
      simple and modifiable - though, I think in the context of the
      dissertation, those properties are guaranteed for the *whole*
      distributed hypermedia system, not necessarily individual components
      within it.

      In any case, nothing will be perceived as simple if you don't
      understand the terminology. In this case, the terms you mention are
      fairly elementary computer science and design patterns. Regardless to
      JAX-RS, a tool, you may find a basic understanding of those terms
      useful.

      To apples and oranges, you may compare the apache daemon architecture
      itself with JAX-RS - I doubt it'd be any more comfortable. Take a
      look at the daemon's Streams[1], for example, compared to JAX-RS.

      --tim

      [1] - http://journal.paul.querna.org/articles/2010/10/06/transforming-streams/
    • Eric J. Bowman
      ... I understand the terminology just fine in the general sense. Understanding REST doesn t require understanding those terms in general, or in how they re
      Message 2 of 30 , Nov 8, 2010
      • 0 Attachment
        Tim Williams wrote:
        >
        > In any case, nothing will be perceived as simple if you don't
        > understand the terminology. In this case, the terms you mention are
        > fairly elementary computer science and design patterns. Regardless to
        > JAX-RS, a tool, you may find a basic understanding of those terms
        > useful.
        >

        I understand the terminology just fine in the general sense.
        Understanding REST doesn't require understanding those terms in general,
        or in how they're applied to REST, and I don't see how such knowledge
        doesn't just get in the way of anyone trying to learn REST. Setting my
        colorful approach to posting aside, the advice I gave the OP shouldn't
        be controversial: instead of starting by choosing the right JAX-RS
        framework, question whether you need JAX-RS or a framework at all.

        -Eric
      • Eric J. Bowman
        ... OK, let s run with that. Most -- not all, but most -- frameworks are locked into the IDL approach (if not IDLs themselves). Resource A allows PUT,
        Message 3 of 30 , Nov 8, 2010
        • 0 Attachment
          Tim Williams wrote:
          >
          > >
          > > See REST 2.3.3 and 2.3.4, then point me to an actual RESTful service
          > > built around JAX-RS which exhibits any of these characteristics.
          > >  For example, configurability seems to be a matter of re-coding the
          > > system. I can't follow any JAX-RS discussions, as they use
          > > terminology that I'm unfamiliar with (injection, marshalling,
          > > controller, persistence, repository and more) in the REST context,
          > > while studiously avoiding any use of terms like "representation" or
          > > "hypertext constraint".  Simply too much complexity for my tastes,
          > > I understand REST just fine without all the enterprisey lingo (or
          > > Java).
          > >
          >
          > I don't know, it seems like you're comparing apples and oranges here.
          > You can use JAX-RS as a tool to build an origin server that is both
          > simple and modifiable - though, I think in the context of the
          > dissertation, those properties are guaranteed for the *whole*
          > distributed hypermedia system, not necessarily individual components
          > within it.
          >

          OK, let's run with that. Most -- not all, but most -- frameworks are
          locked into the IDL approach (if not IDLs themselves). Resource A
          allows PUT, therefore the instructions on how to PUT to A must somehow
          be a product of A. But the hypertext constraint allows resource B to
          describe how to PUT to A, without requiring A to have anything to do
          with that description, or requiring B to have anything to do with A
          beyond containing A's URI as its target.

          Resource B can easily be changed to PUT to C, merely by reconfiguring
          the target URI. Or, the interface to A may be reconfigured by changing
          B (assuming A supports the new configuration, of course). Frameworks
          (with apologies to those I don't mean to lump into my generalizations)
          typically insist that A's interface must be changed by re-coding A.
          Frameworks are great if you're following this IDL pattern, but
          typically throw a royal fit when you try getting them to follow the
          hypertext constraint -- the free-form design approach the hypertext
          constraint allows is a very difficult thing to model generically.

          This is what makes the system, as a whole, not very configurable when
          using frameworks. I ought to be able to reconfigure a system just by
          changing some hyperlinks, not re-thinking the marshalling code or
          changing an IDL (or anything else associated with the distributed-object
          paradigm, as opposed to REST's distributed object *interface* paradigm).
          My thinking on this results from my investigation into creating an in-
          house REST framework -- and deciding against it, in favor of creating a
          configuration framework for REST systems. REST 3.2.1:

          "One aspect of PF styles that is rarely mentioned is that there is an
          implied 'invisible hand' that arranges the configuration of filters in
          order to establish the overall application. A network of filters is
          typically arranged just prior to each activation, allowing the
          application to specify the configuration of filter components based on
          the task at hand and the nature of the data streams (configurability).
          This controller function is considered a separate operational phase of
          the system, and hence a separate architecture, even though one cannot
          exist without the other."

          The desirable property I'm after is the inherent configurability of
          pipe-and-filter architectures. The purpose of a framework is to allow
          resources to be stitched together into a coherent whole. Frameworks
          following the IDL paradigm miss the mark on configurability, by being
          inflexible once the system is stitched together. RESTful IDL-based
          systems are possible, I'm just of the opinion that the results are
          rigid. I see the appeal of the IDL approach to framework development
          (even where IDLs aren't used), but I think this necessarily results in
          a very limited view of REST unsuitable for my style of development.

          These are my opinions, YMMV.

          -Eric
        • William Martinez Pomares
          Erick. ... If you re in a position *not* to ... I didn t want to write it so crude, but I guess I do share some of your position against Jax-RS. You see, there
          Message 4 of 30 , Nov 8, 2010
          • 0 Attachment
            Erick.

            "Eric J. Bowman" wrote:
            >
            If you're in a position *not* to
            > use JAX-RS, then by all means, don't! My reaction to JAX-RS is, "What
            > the hell are you folks even *talking* about?!?" Surely not REST.

            I didn't want to write it so crude, but I guess I do share some of your position against Jax-RS.

            You see, there is an evaluation of frameworks and even a talk I proposed (not accepted yet) on REST frameworks. Obviously, to compare we need a set of criteria, like abstraction level, domain matching, paradigm matching, etc. JAX-RS in particular seems a little wrap of servlets, nothing more that a set of tools to translate HTTP requests into the Java realm (has a couple of nice things, granted), but not of much help to build truly RESTful systems. And as you mention, there is a problem with the domain matching, as you have to learn concepts that are not in the REST domain.

            Anyway, no one will learn to swim without getting wet, so my advice is to try first. And not all are JAX-RS.

            William
          • Eric J. Bowman
            ... To clarify, what does marshalling have to do with REST? I don t see how the term applies, because in the general sense it s about object serialization and
            Message 5 of 30 , Nov 8, 2010
            • 0 Attachment
              Tim Williams wrote:
              >
              > In any case, nothing will be perceived as simple if you don't
              > understand the terminology. In this case, the terms you mention are
              > fairly elementary computer science and design patterns. Regardless to
              > JAX-RS, a tool, you may find a basic understanding of those terms
              > useful.
              >

              To clarify, what does marshalling have to do with REST? I don't see
              how the term applies, because in the general sense it's about object
              serialization and transfer. But, I don't distribute my objects, only
              their interfaces; thus any discussion of marshalling in REST will be
              seen by me as non-sequitir.

              -Eric
            • Eric J. Bowman
              ... I gotta be free to be me. :-) Thanks for the support. -Eric
              Message 6 of 30 , Nov 8, 2010
              • 0 Attachment
                "William Martinez Pomares" wrote:
                >
                > > "What the hell are you folks even *talking* about?!?"
                >
                >
                > I didn't want to write it so crude...
                >

                I gotta be free to be me. :-) Thanks for the support.

                -Eric
              • Tim Williams
                ... I think your confusion stems from your conflating terminology of the style with terminology of the implementation. Marshalling is implementation
                Message 7 of 30 , Nov 8, 2010
                • 0 Attachment
                  On Mon, Nov 8, 2010 at 6:32 PM, Eric J. Bowman <eric@...> wrote:
                  > Tim Williams wrote:
                  >>
                  >> In any case, nothing will be perceived as simple if you don't
                  >> understand the terminology.  In this case, the terms you mention are
                  >> fairly elementary computer science and design patterns.  Regardless to
                  >> JAX-RS, a tool, you may find a basic understanding of those terms
                  >> useful.
                  >>
                  >
                  > To clarify, what does marshalling have to do with REST?  I don't see
                  > how the term applies, because in the general sense it's about object
                  > serialization and transfer.  But, I don't distribute my objects, only
                  > their interfaces; thus any discussion of marshalling in REST will be
                  > seen by me as non-sequitir.

                  I think your confusion stems from your conflating terminology of the
                  style with terminology of the implementation. Marshalling is
                  implementation terminology. Manipulation of resources through
                  representations is terminology of the style.

                  --tim
                • Eric J. Bowman
                  ... Yup. Actually, I d be a lot happier if, as a class, these were called HTTP Frameworks because otherwise, there s an implication that REST is achieved by
                  Message 8 of 30 , Nov 8, 2010
                  • 0 Attachment
                    "William Martinez Pomares" wrote:
                    >
                    > You see, there is an evaluation of frameworks and even a talk I
                    > proposed (not accepted yet) on REST frameworks. Obviously, to compare
                    > we need a set of criteria, like abstraction level, domain matching,
                    > paradigm matching, etc.
                    >

                    Yup. Actually, I'd be a lot happier if, as a class, these were called
                    "HTTP Frameworks" because otherwise, there's an implication that REST
                    is achieved by using the framework. Without implying anything about
                    any framework, RESTlet does indeed directly map REST terminology into
                    configuration. But in reality, a RESTful outcome is the least likely
                    for beginners, regardless of framework. You just can't abstract away
                    having to learn REST; once you have learned, you'll find most frameworks
                    working against you unless their assumptions are congruous with your
                    own.

                    I'd better shut up now, lest I piss off a bunch of people I have a
                    great deal of respect for, who are involved in such work. Instead of
                    comparison criteria, I'd suggest devising two or three REST systems
                    (doesn't have to be anything complicated) as reference, basing your
                    comparison on the implementation experience of each reference across
                    each target framework. I'd also suggest the subjective results be
                    organized in terms of REST 2.3.4 and 2.3.6, with objective results in
                    terms of 2.3.1.1.

                    I'd really be interested in such results, particularly an everything-
                    else-being-equal performance analysis. The test methodology could be
                    duplicated, and anyone else could run the tests on the same frameworks
                    in the future, or newly-introduced frameworks, or as QA if developing a
                    framework. It'd be more work for me to implement the reference systems
                    in my not-a-REST-framework, but I'm sure I'd gain valuable insight by
                    comparing against the subjective experiences of others implementing the
                    same thing on different frameworks.

                    -Eric
                  • Eric J. Bowman
                    ... You re conflating my WTF with confusion. I understand just fine, I just don t see the relevance to REST; IOW, I m not the one who s confused. If your
                    Message 9 of 30 , Nov 8, 2010
                    • 0 Attachment
                      Tim Williams wrote:
                      >
                      > > To clarify, what does marshalling have to do with REST?  I don't see
                      > > how the term applies, because in the general sense it's about object
                      > > serialization and transfer.  But, I don't distribute my objects,
                      > > only their interfaces; thus any discussion of marshalling in REST
                      > > will be seen by me as non-sequitir.
                      >
                      > I think your confusion stems from your conflating terminology of the
                      > style with terminology of the implementation. Marshalling is
                      > implementation terminology. Manipulation of resources through
                      > representations is terminology of the style.
                      >

                      You're conflating my WTF with confusion. I understand just fine, I
                      just don't see the relevance to REST; IOW, I'm not the one who's
                      confused.

                      If your implementation serializes objects for transfer over HTTP, which
                      is exactly what the term "marshalling" refers to in the JAX-RS context,
                      then you're making the same mistake as WS-*/SOAP. That implementation
                      terminology describes a REST anti-pattern, as opposed to the hypertext
                      constraint. (Granted, it's possible to prove me wrong here, but such
                      an explanation won't be reflective of typical systems, based on object
                      serialization and transfer instead of the hypertext constraint.)

                      -Eric
                    • Will Hartung
                      ... Marshalling is the conversion of the byte stream in to the internal structures used (in this case) by the Java program. Not everyone wants to simply work
                      Message 10 of 30 , Nov 8, 2010
                      • 0 Attachment
                        On Mon, Nov 8, 2010 at 4:38 PM, Eric J. Bowman <eric@...> wrote:
                        If your implementation serializes objects for transfer over HTTP, which
                        is exactly what the term "marshalling" refers to in the JAX-RS context,
                        then you're making the same mistake as WS-*/SOAP. That implementation
                        terminology describes a REST anti-pattern, as opposed to the hypertext
                        constraint. (Granted, it's possible to prove me wrong here, but such
                        an explanation won't be reflective of typical systems, based on object
                        serialization and transfer instead of the hypertext constraint.)

                        Marshalling is the conversion of the byte stream in to the internal structures used (in this case) by the Java program. Not everyone wants to simply work with "arrays of bytes" and would rather work with higher level data structures. To be effective with the outside world, one needs to be able to convert to and from these data structures and arrays of bytes.

                        Whether they're converting their data structure to HTML, XHTML, ATOM, or some purpose built representation, and what those representations contain, is not germane to the discussion. One of the benefits of the framework is to make the marshalling process transparent to the overall application.

                        Marshalling is neither an empowering REST process, nor is it a REST killer. It's simply a data conversion process.

                        Regards,

                        Will Hartung
                        (willh@...)

                      • Tim Williams
                        ... Actually, I m asserting your WTF is a result of your confusion, but ok, this is tiring. ... Jave is object-oriented. So any Java web server, by
                        Message 11 of 30 , Nov 8, 2010
                        • 0 Attachment
                          On Mon, Nov 8, 2010 at 7:38 PM, Eric J. Bowman <eric@...> wrote:
                          > Tim Williams wrote:
                          >>
                          >> > To clarify, what does marshalling have to do with REST?  I don't see
                          >> > how the term applies, because in the general sense it's about object
                          >> > serialization and transfer.  But, I don't distribute my objects,
                          >> > only their interfaces; thus any discussion of marshalling in REST
                          >> > will be seen by me as non-sequitir.
                          >>
                          >> I think your confusion stems from your conflating terminology of the
                          >> style with terminology of the implementation. Marshalling is
                          >> implementation terminology.  Manipulation of resources through
                          >> representations is terminology of the style.
                          >>
                          >
                          > You're conflating my WTF with confusion.  I understand just fine, I
                          > just don't see the relevance to REST; IOW, I'm not the one who's
                          > confused.

                          Actually, I'm asserting your 'WTF' is a result of your confusion, but
                          ok, this is tiring.

                          > If your implementation serializes objects for transfer over HTTP, which
                          > is exactly what the term "marshalling" refers to in the JAX-RS context,
                          > then you're making the same mistake as WS-*/SOAP.

                          Jave is object-oriented. So any Java web server, by definition, will
                          serialize objects for transfer over HTTP. Not good, not bad, not a
                          mistake - it just is. You're more likely, imprecisely, referring to
                          folks that use a JavaBean to XML serialization instead of, for
                          example, ROME for Atom representations - but I'm trying to guess what
                          part confuses you.

                          > That implementation
                          > terminology describes a REST anti-pattern, as opposed to the hypertext
                          > constraint.  (Granted, it's possible to prove me wrong here, but such
                          > an explanation won't be reflective of typical systems, based on object
                          > serialization and transfer instead of the hypertext constraint.)

                          It doesn't describe an anti-pattern - its simply factually describes
                          how an Object-Oriented language (like Java) does these things. You
                          seem pretty opinionated on Java frameworks but yet don't come across
                          as a Java programmer?

                          --tim
                        • Eric J. Bowman
                          ... Meaning, the user goal may actually be to view a serialized object, but this would seem to be an atypical, edge case. -Eric
                          Message 12 of 30 , Nov 8, 2010
                          • 0 Attachment
                            >
                            > (Granted, it's possible to prove me wrong here, but such an
                            > explanation won't be reflective of typical systems, based on object
                            > serialization and transfer instead of the hypertext constraint.)
                            >

                            Meaning, the user goal may actually be to view a serialized object, but
                            this would seem to be an atypical, edge case.

                            -Eric
                          • Eric J. Bowman
                            ... The REST paradigm is that your representation is an interface to the object, not the object itself. In REST, implementation details like OOP are hidden
                            Message 13 of 30 , Nov 8, 2010
                            • 0 Attachment
                              Tim Williams wrote:
                              >
                              > Jave is object-oriented. So any Java web server, by definition, will
                              > serialize objects for transfer over HTTP. Not good, not bad, not a
                              > mistake - it just is.
                              >

                              The REST paradigm is that your representation is an interface to the
                              object, not the object itself. In REST, implementation details like
                              OOP are hidden behind the interface, not exposed to the world.

                              >
                              > You're more likely, imprecisely, referring to folks that use a
                              > JavaBean to XML serialization instead of, for example, ROME for Atom
                              > representations - but I'm trying to guess what part confuses you.
                              >

                              I'm not confused. Stating repeatedly that I *am* confused, is an ad-
                              hominem argument. If you want to enlighten me, that isn't how to go
                              about it. I can't imagine what an object would look like, which
                              serializes into an HTML form. Yeah, you can serialize objects into
                              Atom, butt-ugly Atom; but that isn't the REST paradigm where the
                              representation is an interface to the object, not the object itself.

                              >
                              > It doesn't describe an anti-pattern - its simply factually describes
                              > how an Object-Oriented language (like Java) does these things. You
                              > seem pretty opinionated on Java frameworks but yet don't come across
                              > as a Java programmer?
                              >

                              No, I don't know Java. But that's irrelevant to the point I'm making,
                              which is that JAX-RS contains terminology which has everything to do
                              with Java and nothing to do with REST. Personally, Java cost my
                              project years, and was a mistake to pursue -- I am not an enterprise.

                              -Eric
                            • Eric J. Bowman
                              ... I don t understand. The content of the representation is what I look at to determine whether the hypertext constraint is applied. None of the examples
                              Message 14 of 30 , Nov 8, 2010
                              • 0 Attachment
                                Will Hartung wrote:
                                >
                                > Whether they're converting their data structure to HTML, XHTML, ATOM,
                                > or some purpose built representation, and what those representations
                                > contain, is not germane to the discussion.
                                >

                                I don't understand. The content of the representation is what I look
                                at to determine whether the hypertext constraint is applied. None of
                                the examples I've seen of marshalling in JAX-RS look like hypertext
                                which drives application state, they look like serialized objects. If
                                I'm looking at bad examples, please direct my attention to good
                                examples.

                                -Eric
                              • Will Hartung
                                ... And...you blame those representations on the MARSHALLING? Talk about killing the messenger. JAX-RS is a mechanism of mapping HTTP requests, handling
                                Message 15 of 30 , Nov 8, 2010
                                • 0 Attachment
                                  On Mon, Nov 8, 2010 at 5:33 PM, Eric J. Bowman <eric@...> wrote:
                                  > Will Hartung wrote:
                                  >>
                                  >> Whether they're converting their data structure to HTML, XHTML, ATOM,
                                  >> or some purpose built representation, and what those representations
                                  >> contain, is not germane to the discussion.
                                  >>
                                  >
                                  > I don't understand.  The content of the representation is what I look
                                  > at to determine whether the hypertext constraint is applied.  None of
                                  > the examples I've seen of marshalling in JAX-RS look like hypertext
                                  > which drives application state, they look like serialized objects.  If
                                  > I'm looking at bad examples, please direct my attention to good
                                  > examples.

                                  And...you blame those representations on the MARSHALLING? Talk about
                                  killing the messenger.

                                  JAX-RS is a mechanism of mapping HTTP requests, handling internal
                                  method dispatch and routing, URL decoding and data marshalling. The
                                  fact that people don't use this in a RESTful way, or that the examples
                                  are not RESTful doesn't mean that framework isn't a good choice for
                                  implementing a RESTful system in the Java environment. Seems to me,
                                  not being a heavy user of it, that it manages much of the boiler plate
                                  processing that many HTTP transactions must perform, and manages it
                                  better than the raw Servlet spec.

                                  Perhaps it could have been better named than JAX-RS, but it's
                                  certainly enables a more RESTful style of development than JAX-WS.

                                  Regards,

                                  Will Hartung
                                  (willh@...)
                                • Eric J. Bowman
                                  ... Whenever I come across REST articles presented with JAX-RS examples, the examples are serialized objects and the discussion is marshalling, to the extent
                                  Message 16 of 30 , Nov 8, 2010
                                  • 0 Attachment
                                    Will Hartung wrote:
                                    >
                                    > > I don't understand.  The content of the representation is what I
                                    > > look at to determine whether the hypertext constraint is applied.
                                    > >  None of the examples I've seen of marshalling in JAX-RS look like
                                    > > hypertext which drives application state, they look like serialized
                                    > > objects.  If I'm looking at bad examples, please direct my
                                    > > attention to good examples.
                                    >
                                    > And...you blame those representations on the MARSHALLING? Talk about
                                    > killing the messenger.
                                    >

                                    Whenever I come across REST articles presented with JAX-RS examples,
                                    the examples are serialized objects and the discussion is marshalling,
                                    to the extent that I believe that in the common vernacular, marshalling
                                    refers to a REST anti-pattern in JAX-RS. If it's supposed to mean
                                    something else, or isn't tied to the meaning I perceive from those
                                    examples, I've seen no evidence but would appreciate links to any.

                                    >
                                    > JAX-RS is a mechanism of mapping HTTP requests, handling internal
                                    > method dispatch and routing, URL decoding and data marshalling. The
                                    > fact that people don't use this in a RESTful way, or that the examples
                                    > are not RESTful doesn't mean that framework isn't a good choice for
                                    > implementing a RESTful system in the Java environment.
                                    >

                                    I believe I've said the same thing, twice. The issue is, if you don't
                                    have good reason (i.e. legacy Java system), the additional terminology
                                    obscures "what is REST" and leads to confusion -- if I'm confused about
                                    what marshalling means in JAX-RS, which I may be, it results from the
                                    confusing way the term is used in practice to refer to something foreign
                                    to REST (while claiming to be REST by virtue of using JAX-RS). Better
                                    to avoid that confusion if possible.

                                    -Eric
                                  • Eric J. Bowman
                                    ... The corollary is, of course, the widespread misconception that REST limits you to four HTTP methods which map to CRUD. Except in that case, there are
                                    Message 17 of 30 , Nov 8, 2010
                                    • 0 Attachment
                                      >
                                      > Whenever I come across REST articles presented with JAX-RS examples,
                                      > the examples are serialized objects and the discussion is marshalling,
                                      > to the extent that I believe that in the common vernacular,
                                      > marshalling refers to a REST anti-pattern in JAX-RS. If it's
                                      > supposed to mean something else, or isn't tied to the meaning I
                                      > perceive from those examples, I've seen no evidence but would
                                      > appreciate links to any.
                                      >

                                      The corollary is, of course, the widespread misconception that REST
                                      limits you to four HTTP methods which map to CRUD. Except in that
                                      case, there are plenty of examples available which refute the notion.
                                      I've never mocked anyone for holding that belief -- it's understandable
                                      given how pervasive it is -- only politely set them on the right path.

                                      -Eric
                                    • Eric J. Bowman
                                      ... Oh, absolutely. Plus, annotations are interesting. So are URI templates. In fact, there s lots of good stuff there. But for some reason, AFAICT, the
                                      Message 18 of 30 , Nov 8, 2010
                                      • 0 Attachment
                                        Will Hartung wrote:
                                        >
                                        > Perhaps it could have been better named than JAX-RS, but it's
                                        > certainly enables a more RESTful style of development than JAX-WS.
                                        >

                                        Oh, absolutely. Plus, annotations are interesting. So are URI
                                        templates. In fact, there's lots of good stuff there. But for some
                                        reason, AFAICT, the result isn't a proliferation of RESTful services
                                        based on it. I think the reason for this is the terminology, like
                                        "marshalling", is being applied to REST exactly the same way it was
                                        applied (in the Java world) to WS-*/SOAP, rather than in the generic
                                        sense. Just my opinion.

                                        -Eric
                                      • Tim Williams
                                        ... No one s suggested otherwise Eric. You ve got a beef - clearly. I m trying to help you understand that your beef really isn t with marshalling - a
                                        Message 19 of 30 , Nov 8, 2010
                                        • 0 Attachment
                                          On Mon, Nov 8, 2010 at 8:27 PM, Eric J. Bowman <eric@...> wrote:
                                          > Tim Williams wrote:
                                          >>
                                          >> Jave is object-oriented.  So any Java web server, by definition, will
                                          >> serialize objects for transfer over HTTP.  Not good, not bad, not a
                                          >> mistake - it just is.
                                          >>
                                          >
                                          > The REST paradigm is that your representation is an interface to the
                                          > object, not the object itself.  In REST, implementation details like
                                          > OOP are hidden behind the interface, not exposed to the world.

                                          No one's suggested otherwise Eric. You've got a beef - clearly. I'm
                                          trying to help you understand that your beef really isn't with
                                          "marshalling" - a factual necessity - it seems to be with developer's
                                          lazy out of the box JAXB JavaBean-to-XML object serialization.

                                          >> You're more likely, imprecisely, referring to folks that use a
                                          >> JavaBean to XML serialization instead of, for example, ROME for Atom
                                          >> representations - but I'm trying to guess what part confuses you.
                                          >>
                                          >
                                          > I'm not confused.  Stating repeatedly that I *am* confused, is an ad-
                                          > hominem argument.  If you want to enlighten me, that isn't how to go
                                          > about it.  I can't imagine what an object would look like, which
                                          > serializes into an HTML form.  Yeah, you can serialize objects into
                                          > Atom, butt-ugly Atom; but that isn't the REST paradigm where the
                                          > representation is an interface to the object, not the object itself.

                                          I won't again say you're confused:) I'll instead say you've latched
                                          on to a term "marshalling" and projected upon it way too much meaning.
                                          It's also poor inductive reasoning. You've observed that folks using
                                          JAX-RS to do simple objective serialization (a la JAXB) and you've
                                          apparently concluded that therefore all folks using JAX-RS must do
                                          simple object serialization. The truth is, JAX-RS as with most
                                          so-called REST Frameworks are tools that *can* support RESTful
                                          services but can also lead to bad implementations. That's not
                                          necessarily the fault of the framework. For example, most Jersey code
                                          that's around me is using ROME to produce Atom but it's pretty close
                                          to this:

                                          http://weblogs.java.net/blog/2008/02/05/integrating-jersey-and-abdera

                                          >> It doesn't describe an anti-pattern - its simply factually describes
                                          >> how an Object-Oriented language (like Java) does these things.  You
                                          >> seem pretty opinionated on Java frameworks but yet don't come across
                                          >> as a Java programmer?
                                          >>
                                          >
                                          > No, I don't know Java.  But that's irrelevant to the point I'm making,
                                          > which is that JAX-RS contains terminology which has everything to do
                                          > with Java and nothing to do with REST.  Personally, Java cost my
                                          > project years, and was a mistake to pursue -- I am not an enterprise.

                                          I'd suggest that your lack of experience with Java and JAX-RS is
                                          limiting your ability to provide a useful critique on the subject. I
                                          don't see much "marshalling", but I see

                                          Architecture - > Implementation
                                          Uniform Interface - > @GET, @POST, etc.
                                          Resources manipulated - > @ProducesMime, @ConsumesMime
                                          through representations
                                          URI -> @Path
                                          Hypermedia -> @Ref, @Produces, etc.

                                          You get the idea. It's not perfect, but the tools are there to
                                          support an implementation that lives within the REST constraints.
                                          Maybe I'm comfortable enough with Java not to notice Java-ish
                                          terminology but when read the guide:

                                          http://jersey.java.net/nonav/documentation/latest/user-guide.html#d0e2522

                                          ... I think they've done a pretty good job at sticking to the
                                          resources, representations, URI, etc. speak.

                                          --tim
                                        • William Martinez Pomares
                                          Will, I m playing devil s advocate here... Yes, JAX-RS helps in what you say, but as you say it seems more like an improved servlet. Not bad, maybe not what
                                          Message 20 of 30 , Nov 8, 2010
                                          • 0 Attachment
                                            Will, I'm playing devil's advocate here...
                                            Yes, JAX-RS helps in what you say, but as you say it seems more like an improved servlet. Not bad, maybe not what REST needs either. Only the fact of annotating a method is suspicious, and as you can see from the post, may be confused with RPC very easily.

                                            William Martinez.

                                            --- In rest-discuss@yahoogroups.com, Will Hartung <willh@...> wrote:
                                            >
                                            > On Mon, Nov 8, 2010 at 5:33 PM, Eric J. Bowman <eric@...> wrote:
                                            > > Will Hartung wrote:
                                            > >>
                                            > >> Whether they're converting their data structure to HTML, XHTML, ATOM,
                                            > >> or some purpose built representation, and what those representations
                                            > >> contain, is not germane to the discussion.
                                            > >>
                                            > >
                                            > > I don't understand.  The content of the representation is what I look
                                            > > at to determine whether the hypertext constraint is applied.  None of
                                            > > the examples I've seen of marshalling in JAX-RS look like hypertext
                                            > > which drives application state, they look like serialized objects.  If
                                            > > I'm looking at bad examples, please direct my attention to good
                                            > > examples.
                                            >
                                            > And...you blame those representations on the MARSHALLING? Talk about
                                            > killing the messenger.
                                            >
                                            > JAX-RS is a mechanism of mapping HTTP requests, handling internal
                                            > method dispatch and routing, URL decoding and data marshalling. The
                                            > fact that people don't use this in a RESTful way, or that the examples
                                            > are not RESTful doesn't mean that framework isn't a good choice for
                                            > implementing a RESTful system in the Java environment. Seems to me,
                                            > not being a heavy user of it, that it manages much of the boiler plate
                                            > processing that many HTTP transactions must perform, and manages it
                                            > better than the raw Servlet spec.
                                            >
                                            > Perhaps it could have been better named than JAX-RS, but it's
                                            > certainly enables a more RESTful style of development than JAX-WS.
                                            >
                                            > Regards,
                                            >
                                            > Will Hartung
                                            > (willh@...)
                                            >
                                          • William Martinez Pomares
                                            Me again. Marshalling is not to blame, actually. Point granted. When you marshall, you create a structure in Java, an object. That structure can be a direct
                                            Message 21 of 30 , Nov 8, 2010
                                            • 0 Attachment
                                              Me again.
                                              Marshalling is not to blame, actually. Point granted.
                                              When you marshall, you create a structure in Java, an object. That structure can be a direct domain object or a metadata structure.

                                              1. Using a domain object is great, as you work directly with the domain, but that may force the domain outwards and you may have some impedance mismatch.
                                              2. Using metadata (that is, an object that knows how to work with HTML for instance), has the benefit of still using object, but managing the original data (the HTML in this case). The con is the poor insertion into the domain.

                                              Still, not all incoming representations should be mapped into domain objects, some may be kept in metadata, and the resource should not necessarily be an object.

                                              Again, not all is the framework's fault, and the framework alone will not make the thinking work for you.


                                              William Martinez.

                                              --- In rest-discuss@yahoogroups.com, Will Hartung <willh@...> wrote:
                                              >
                                              > On Mon, Nov 8, 2010 at 4:38 PM, Eric J. Bowman <eric@...>wrote:
                                              >
                                              > > If your implementation serializes objects for transfer over HTTP, which
                                              > > is exactly what the term "marshalling" refers to in the JAX-RS context,
                                              > > then you're making the same mistake as WS-*/SOAP. That implementation
                                              > > terminology describes a REST anti-pattern, as opposed to the hypertext
                                              > > constraint. (Granted, it's possible to prove me wrong here, but such
                                              > > an explanation won't be reflective of typical systems, based on object
                                              > > serialization and transfer instead of the hypertext constraint.)
                                              > >
                                              >
                                              > Marshalling is the conversion of the byte stream in to the internal
                                              > structures used (in this case) by the Java program. Not everyone wants to
                                              > simply work with "arrays of bytes" and would rather work with higher level
                                              > data structures. To be effective with the outside world, one needs to be
                                              > able to convert to and from these data structures and arrays of bytes.
                                              >
                                              > Whether they're converting their data structure to HTML, XHTML, ATOM, or
                                              > some purpose built representation, and what those representations contain,
                                              > is not germane to the discussion. One of the benefits of the framework is to
                                              > make the marshalling process transparent to the overall application.
                                              >
                                              > Marshalling is neither an empowering REST process, nor is it a REST killer.
                                              > It's simply a data conversion process.
                                              >
                                              > Regards,
                                              >
                                              > Will Hartung
                                              > (willh@...)
                                              >
                                            • Eric J. Bowman
                                              ... Me just being me, tends to fool people into thinking I have beeves when I don t. I ve been very careful to discuss confusion surrounding terminology,
                                              Message 22 of 30 , Nov 8, 2010
                                              • 0 Attachment
                                                Tim Williams wrote:
                                                >
                                                > No one's suggested otherwise Eric. You've got a beef - clearly. I'm
                                                > trying to help you understand that your beef really isn't with
                                                > "marshalling" - a factual necessity - it seems to be with developer's
                                                > lazy out of the box JAXB JavaBean-to-XML object serialization.
                                                >

                                                Me just being me, tends to fool people into thinking I have beeves when
                                                I don't. I've been very careful to discuss confusion surrounding
                                                terminology, rather than staking out a "JAX-RS considered harmful"
                                                position. I appreciate your helping me to work through this, but I
                                                also think there are lessons to be learned (given that this *is* rest-
                                                discuss) by analyzing where, why and how folks wind up somewhere other
                                                than REST when using frameworks crafted specifically to support REST.

                                                Case in point, is that so many folks are apparently misappropriating
                                                the terminology that I've been misled by reading them, a la REST=CRUD,
                                                into believing (for example) that marshalling is what people do when
                                                they don't understand the hypertext constraint. Using the same term
                                                which in WS-* meant "serialize to SOAP" may mean that it's preferable
                                                to avoid the term in framework documentation, to avoid such confusion.

                                                >
                                                > I won't again say you're confused:) I'll instead say you've latched
                                                > on to a term "marshalling" and projected upon it way too much meaning.
                                                >

                                                Well, that, or I adopted the meaning that's most prevalent in the
                                                material I've read -- which means it's others who have projected too
                                                much, or an incorrect, meaning onto the term in their own confusion.

                                                >
                                                > It's also poor inductive reasoning. You've observed that folks using
                                                > JAX-RS to do simple objective serialization (a la JAXB) and you've
                                                > apparently concluded that therefore all folks using JAX-RS must do
                                                > simple object serialization.
                                                >

                                                If I thought that, I would've staked out "JAX-RS considered harmful" as
                                                my position, instead of the position that the terminology is leading
                                                folks astray (for whatever reason), and is best avoided by those trying
                                                to learn.

                                                >
                                                > The truth is, JAX-RS as with most so-called REST Frameworks are tools
                                                > that *can* support RESTful services but can also lead to bad
                                                > implementations. That's not necessarily the fault of the framework.
                                                >

                                                No, you're right -- it could result from the documentation and articles
                                                about the frameworks. Four to five years ago, there was no such thing
                                                as a REST framework, now they're myriad, but we're still in the first
                                                generation. Moving forward, there's some value to examining the
                                                reasons why the appearance of these frameworks hasn't really led to
                                                more examples of honest-to-gosh REST in the wild. I kinda thought they
                                                would...

                                                >
                                                > For example, most Jersey code that's around me is using ROME to
                                                > produce Atom but it's pretty close to this:
                                                >
                                                > http://weblogs.java.net/blog/2008/02/05/integrating-jersey-and-abdera
                                                >
                                                > >> It doesn't describe an anti-pattern - its simply factually
                                                > >> describes how an Object-Oriented language (like Java) does these
                                                > >> things.  You seem pretty opinionated on Java frameworks but yet
                                                > >> don't come across as a Java programmer?
                                                > >>
                                                > >
                                                > > No, I don't know Java.  But that's irrelevant to the point I'm
                                                > > making, which is that JAX-RS contains terminology which has
                                                > > everything to do with Java and nothing to do with REST.
                                                > >  Personally, Java cost my project years, and was a mistake to
                                                > > pursue -- I am not an enterprise.
                                                >
                                                > I'd suggest that your lack of experience with Java and JAX-RS is
                                                > limiting your ability to provide a useful critique on the subject.
                                                >

                                                Perhaps. OTOH, the OP didn't give us much in the way of details about
                                                his project or experience, so I decided not to make any assumptions
                                                about that, or why he thinks a Java-based framework is the way to go.
                                                Given that he may indeed be new to both REST and Java, I feel my advice
                                                was spot-on -- if, given my knowledge and experience, I can't relate
                                                discussions of JAX-RS to REST, what hope is there for someone new to
                                                the field to succeed in bringing a system to market that way?

                                                >
                                                > Architecture - > Implementation
                                                > Uniform Interface - > @GET, @POST, etc.
                                                > Resources manipulated - > @ProducesMime, @ConsumesMime
                                                > through representations
                                                > URI -> @Path
                                                > Hypermedia -> @Ref, @Produces, etc.
                                                >

                                                Well, yeah, on this level it makes sense. But when the discussion
                                                turns to implementation, there's a whole world of terminology that
                                                simply isn't encountered in REST, outside of Java -- terms I'm familiar
                                                with outside of REST, applied in a way that doesn't make sense to me
                                                within REST. As I've said, the terminology seems to bring the WS-*/SOAP
                                                paradigm along with it, which is why I challenged the notion of using
                                                Java, JAX-RS or frameworks in general, as a starting point. Frameworks
                                                are HTTP libraries mistaken for REST libraries, as if REST's constraints
                                                may be abstracted away as easily as generating cache headers (which may
                                                eventually be the case, but we're nowhere near that today).

                                                >
                                                > You get the idea. It's not perfect, but the tools are there to
                                                > support an implementation that lives within the REST constraints.
                                                > Maybe I'm comfortable enough with Java not to notice Java-ish
                                                > terminology but when read the guide:
                                                >
                                                > http://jersey.java.net/nonav/documentation/latest/user-guide.html#d0e2522
                                                >
                                                > ... I think they've done a pretty good job at sticking to the
                                                > resources, representations, URI, etc. speak.
                                                >

                                                OK, thanks for the links, I'll go read them now, with an eye towards
                                                figuring out where the disconnect lies -- such that when it comes time
                                                to document my own solution, I don't fall into the same traps and see my
                                                own work horrifyingly used to recast SOAP. :-0

                                                -Eric
                                              Your message has been successfully submitted and would be delivered to recipients shortly.