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

ATOM Pub vs. JSON vs. ...?

Expand Messages
  • Kristian Rink
    Folks; I am at the moment into trying to choose a data format / representation to use for building a RESTful web service which should allow for reading and
    Message 1 of 15 , May 29, 2012
      Folks;

      I am at the moment into trying to choose a data format / representation
      to use for building a RESTful web service which should allow for reading
      and writing resources, which should be accessible using "standard" tools
      as well as using a dedicated programming API and which should as much as
      somewhat possible rely upon existing open standards.

      After doing some reading, I came across Atom and APP as it seems in many
      possible ways provide sane and stable solutions for problems at hand
      (including things like "workspaces", "feeds", "entries", dealing with
      service and category descriptions, dealing with textual and binary
      content, dealing with extensibility and stuff like OpenSearch and the
      like).

      In many ways, so far it seems the perfect match, however it right now
      (at least for me) suffers from a particular shortcoming: I am not really
      sure whether it's a technology or a standard to "last". Doing some
      reading on that, I rather quickly stumbled across articles pointing out
      that "AtomPub has failed" and "AtomPub is basically dead", suggesting
      that everyone else uses JSON based REST services right now, eventually
      pointing out that even the Google GData services are considered "legacy"
      and replaced by different approaches right now. On the other hand I
      don't really see what could replace Atom or especially AtomPub talking
      about providing a given data structure, a data and service semantics to
      allow for read/write interactions with a service in a somewhat sane,
      standard way.

      So to ask: If you were about to start a new RESTful project supposed to
      work with existing "standard" tools, what kind of data representation
      would you choose? Would you still go for Atom / AtomPub? Would you
      rather use some kind of JSON+HTTP? Something completely else?

      Thanks in advance for any input,
      Kristian
    • Steve Klabnik
      PubSubHubbub is also pretty neat, though I haven t considered it from a REST purist perspective.
      Message 2 of 15 , May 29, 2012
        PubSubHubbub is also pretty neat, though I haven't considered it from
        a REST purist perspective.
      • Mike Kelly
        Hi Kristian, I think one of the major problems with Atom/APP is that it was too specific to become a general-use media type- there are many resources and
        Message 3 of 15 , May 29, 2012
          Hi Kristian,

          I think one of the major problems with Atom/APP is that it was too
          specific to become a 'general-use' media type- there are many
          resources and applications that do not fit into a collection and item
          mode and so 'standard' tooling that is built on top of it is only
          applicable in specific circumstances - which limits the tools'
          value/utility.

          I believe if we take a different approach whereby the fundamental
          model of a generic media type is based around resources (_not_
          collections) then we can better develop tooling that will be more
          generally aplicable, and more likely to be adopted on the whole.

          I took these ideas and created a couple of media types hal+json and
          hal+xml that are designed on that basis. They allow you to model your
          application in terms of resources and links, and will make your app
          consumable from a number of open source libraries. You can read more
          about them here if you are interested:

          http://blog.stateless.co/post/13296666138/json-linking-with-hal
          http://stateless.co/hal_specification.html

          Cheers,
          M

          On Tue, May 29, 2012 at 2:23 PM, Kristian Rink <kawazu428@...> wrote:
          > Folks;
          >
          > I am at the moment into trying to choose a data format / representation
          > to use for building a RESTful web service which should allow for reading
          > and writing resources, which should be accessible using "standard" tools
          > as well as using a dedicated programming API and which should as much as
          > somewhat possible rely upon existing open standards.
          >
          > After doing some reading, I came across Atom and APP as it seems in many
          > possible ways provide sane and stable solutions for problems at hand
          > (including things like "workspaces", "feeds", "entries", dealing with
          > service and category descriptions, dealing with textual and binary
          > content, dealing with extensibility and stuff like OpenSearch and the
          > like).
          >
          > In many ways, so far it seems the perfect match, however it right now
          > (at least for me) suffers from a particular shortcoming: I am not really
          > sure whether it's a technology or a standard to "last". Doing some
          > reading on that, I rather quickly stumbled across articles pointing out
          > that "AtomPub has failed" and "AtomPub is basically dead", suggesting
          > that everyone else uses JSON based REST services right now, eventually
          > pointing out that even the Google GData services are considered "legacy"
          > and replaced by different approaches right now. On the other hand I
          > don't really see what could replace Atom or especially AtomPub talking
          > about providing a given data structure, a data and service semantics to
          > allow for read/write interactions with a service in a somewhat sane,
          > standard way.
          >
          > So to ask: If you were about to start a new RESTful project supposed to
          > work with existing "standard" tools, what kind of data representation
          > would you choose? Would you still go for Atom / AtomPub? Would you
          > rather use some kind of JSON+HTTP? Something completely else?
          >
          > Thanks in advance for any input,
          > Kristian
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >



          --
          Mike

          http://twitter.com/mikekelly85
          http://github.com/mikekelly
          http://linkedin.com/in/mikekelly123
        • mike amundsen
          no matter the assessments of the success or failure of Atom/APP, it s not going away any time soon. If the data format and message semantics work for your
          Message 4 of 15 , May 29, 2012
            no matter the assessments of the "success" or "failure" of Atom/APP, it's not going away any time soon. If the data format and message semantics work for your use case, I would not hesitate to use it in your implementation.

            Other media type designs that you might want to check out are HAL[1] and Collection+JSON[2]. Both aim at similar space and have markedly different approaches. 



            mca
            http://amundsen.com/blog/
            http://twitter.com@mamund
            http://mamund.com/foaf.rdf#me





            On Tue, May 29, 2012 at 12:01 PM, Steve Klabnik <steve@...> wrote:
            PubSubHubbub is also pretty neat, though I haven't considered it from
            a REST purist perspective.


            ------------------------------------

            Yahoo! Groups Links

            <*> To visit your group on the web, go to:
               http://groups.yahoo.com/group/rest-discuss/

            <*> Your email settings:
               Individual Email | Traditional

            <*> To change settings online go to:
               http://groups.yahoo.com/group/rest-discuss/join
               (Yahoo! ID required)

            <*> To change settings via email:
               rest-discuss-digest@yahoogroups.com
               rest-discuss-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
               rest-discuss-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
               http://docs.yahoo.com/info/terms/


          • Glenn Block
            Collection+JSON or HAL+JSON might also meet your needs. Both are very new standards Sent from my Windows Phone From: Kristian Rink Sent: 5/29/2012 8:58 AM To:
            Message 5 of 15 , May 29, 2012
              Collection+JSON or HAL+JSON might also meet your needs. Both are very
              new standards

              Sent from my Windows Phone
              From: Kristian Rink
              Sent: 5/29/2012 8:58 AM
              To: Rest List
              Subject: [rest-discuss] ATOM Pub vs. JSON vs. ...?
              Folks;

              I am at the moment into trying to choose a data format / representation
              to use for building a RESTful web service which should allow for reading
              and writing resources, which should be accessible using "standard" tools
              as well as using a dedicated programming API and which should as much as
              somewhat possible rely upon existing open standards.

              After doing some reading, I came across Atom and APP as it seems in many
              possible ways provide sane and stable solutions for problems at hand
              (including things like "workspaces", "feeds", "entries", dealing with
              service and category descriptions, dealing with textual and binary
              content, dealing with extensibility and stuff like OpenSearch and the
              like).

              In many ways, so far it seems the perfect match, however it right now
              (at least for me) suffers from a particular shortcoming: I am not really
              sure whether it's a technology or a standard to "last". Doing some
              reading on that, I rather quickly stumbled across articles pointing out
              that "AtomPub has failed" and "AtomPub is basically dead", suggesting
              that everyone else uses JSON based REST services right now, eventually
              pointing out that even the Google GData services are considered "legacy"
              and replaced by different approaches right now. On the other hand I
              don't really see what could replace Atom or especially AtomPub talking
              about providing a given data structure, a data and service semantics to
              allow for read/write interactions with a service in a somewhat sane,
              standard way.

              So to ask: If you were about to start a new RESTful project supposed to
              work with existing "standard" tools, what kind of data representation
              would you choose? Would you still go for Atom / AtomPub? Would you
              rather use some kind of JSON+HTTP? Something completely else?

              Thanks in advance for any input,
              Kristian


              ------------------------------------

              Yahoo! Groups Links
            • Rushforth, Peter
              Hey Kristian, AtomPub is awesome! Go for it. Nothing stops you from using content negotiation to provide other formats within the scope of your service. Just
              Message 6 of 15 , May 29, 2012
                Hey Kristian,

                AtomPub is awesome! Go for it. Nothing stops you from using
                content negotiation to provide other formats within the scope of your
                service.

                Just remember that when you extend it with
                your own markup, you should use appropriate message metadata / extended
                MIME media types you use to encompass your extensions.


                Cheers,
                Peter



                > -----Original Message-----
                > From: rest-discuss@yahoogroups.com
                > [mailto:rest-discuss@yahoogroups.com] On Behalf Of Kristian Rink
                > Sent: May 29, 2012 09:23
                > To: Rest List
                > Subject: [rest-discuss] ATOM Pub vs. JSON vs. ...?
                >
                > Folks;
                >
                > I am at the moment into trying to choose a data format /
                > representation to use for building a RESTful web service
                > which should allow for reading and writing resources, which
                > should be accessible using "standard" tools as well as using
                > a dedicated programming API and which should as much as
                > somewhat possible rely upon existing open standards.
                >
                > After doing some reading, I came across Atom and APP as it
                > seems in many possible ways provide sane and stable solutions
                > for problems at hand (including things like "workspaces",
                > "feeds", "entries", dealing with service and category
                > descriptions, dealing with textual and binary content,
                > dealing with extensibility and stuff like OpenSearch and the like).
                >
                > In many ways, so far it seems the perfect match, however it
                > right now (at least for me) suffers from a particular
                > shortcoming: I am not really sure whether it's a technology
                > or a standard to "last". Doing some reading on that, I rather
                > quickly stumbled across articles pointing out that "AtomPub
                > has failed" and "AtomPub is basically dead", suggesting that
                > everyone else uses JSON based REST services right now,
                > eventually pointing out that even the Google GData services
                > are considered "legacy"
                > and replaced by different approaches right now. On the other
                > hand I don't really see what could replace Atom or especially
                > AtomPub talking about providing a given data structure, a
                > data and service semantics to allow for read/write
                > interactions with a service in a somewhat sane, standard way.
                >
                > So to ask: If you were about to start a new RESTful project
                > supposed to work with existing "standard" tools, what kind of
                > data representation would you choose? Would you still go for
                > Atom / AtomPub? Would you rather use some kind of JSON+HTTP?
                > Something completely else?
                >
                > Thanks in advance for any input,
                > Kristian
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • Philippe Rathé
                Hi Kristian, how could be atompub dead? People are just starting to understand REST, how could someone choose atompub when he doesn t understand REST? I m
                Message 7 of 15 , May 29, 2012
                  Hi Kristian,

                  how could be atompub dead? People are just starting to understand
                  REST, how could someone choose atompub when he doesn't understand
                  REST?

                  I'm starting to work on a side project that make uses of APP. I also
                  noticed that it wasn't trendy. But when I realize
                  the reasons were that nobody cares about interoperability and
                  hypermedia driven application state,
                  then my fear disappeared because I care. XML may be less trendy than
                  JSON, that was I used to think. But I found my trend: XQuery in the
                  backend and a native XML database, storing my feeds as-is.

                  I felt that working with APP could be a good knowledge investment.
                  That was a decision that came from my heart first. I recognized
                  something strong in it.

                  Good luck!

                  On Tue, May 29, 2012 at 9:23 AM, Kristian Rink <kawazu428@...> wrote:
                  > Folks;
                  >
                  > I am at the moment into trying to choose a data format / representation
                  > to use for building a RESTful web service which should allow for reading
                  > and writing resources, which should be accessible using "standard" tools
                  > as well as using a dedicated programming API and which should as much as
                  > somewhat possible rely upon existing open standards.
                  >
                  > After doing some reading, I came across Atom and APP as it seems in many
                  > possible ways provide sane and stable solutions for problems at hand
                  > (including things like "workspaces", "feeds", "entries", dealing with
                  > service and category descriptions, dealing with textual and binary
                  > content, dealing with extensibility and stuff like OpenSearch and the
                  > like).
                  >
                  > In many ways, so far it seems the perfect match, however it right now
                  > (at least for me) suffers from a particular shortcoming: I am not really
                  > sure whether it's a technology or a standard to "last". Doing some
                  > reading on that, I rather quickly stumbled across articles pointing out
                  > that "AtomPub has failed" and "AtomPub is basically dead", suggesting
                  > that everyone else uses JSON based REST services right now, eventually
                  > pointing out that even the Google GData services are considered "legacy"
                  > and replaced by different approaches right now. On the other hand I
                  > don't really see what could replace Atom or especially AtomPub talking
                  > about providing a given data structure, a data and service semantics to
                  > allow for read/write interactions with a service in a somewhat sane,
                  > standard way.
                  >
                  > So to ask: If you were about to start a new RESTful project supposed to
                  > work with existing "standard" tools, what kind of data representation
                  > would you choose? Would you still go for Atom / AtomPub? Would you
                  > rather use some kind of JSON+HTTP? Something completely else?
                  >
                  > Thanks in advance for any input,
                  > Kristian
                  >
                  >
                  > ------------------------------------
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                • Kristian Rink
                  Folks; and first off, thanks very much for your input on this, greatly appreciated! :) ... Well actually, despite knowing there actually always will be some
                  Message 8 of 15 , May 29, 2012
                    Folks;

                    and first off, thanks very much for your input on this, greatly
                    appreciated! :)

                    Am 29.05.2012 18:18, schrieb mike amundsen:
                    > no matter the assessments of the "success" or "failure" of Atom/APP,
                    > it's not going away any time soon. If the data format and message
                    > semantics work for your use case, I would not hesitate to use it in your
                    > implementation.

                    Well actually, despite knowing there actually always will be some
                    differences in "mapping" a custom data semantics to an existing one, I
                    figured out that, in our given use case, the concepts of Atom and APP
                    both fit better than any other approach I found so far, and, then again,
                    seem to be backed by sufficient support (frameworks, documentation,
                    tools out there) to eventually provide a reliable foundation being a
                    "primary representation" in a prototype system that doesn't want to come
                    up with a custom / proprietary API which essentially wouldn't do much
                    more than re-inventing things like workspaces, feeds, entries,
                    categories (one of the things about Atom that definitely got me
                    enthusiastic about it when I started dealing with it) or representations
                    accepted when POSTing things to a certain resource.

                    So far, my only real doubt here was, after reading through all the posts
                    I found out there, that Atom / APP might not be "state of the art" here
                    anymore. AFAICT, most of the frameworks and librares I stumbled across
                    (in the Java/Java EE world) seem not to have seen major updates in a
                    while. I simply wouldn't like to do an up-front design of a new system
                    built upon something obsolete in the beginning. So far, your comments
                    have merely convinced me that going with Atom / APP seems a good
                    starting point initially.


                    > Other media type designs that you might want to check out are HAL[1]
                    > and Collection+JSON[2]. Both aim at similar space and have markedly
                    > different approaches.
                    >
                    > [1] http://stateless.co/hal_specification.html
                    > [2] http://amundsen.com/media-types/collection/

                    Thanks very much for the pointers. I'll have a look for sure and see
                    whether one of these (or both) might come in at least as an alternative
                    representation usable by clients that can't / don't want to work with
                    Atom. At first sight, especially HAL seems promising; curious to work
                    with this a bit. :)

                    Thanks again, all the best!
                    Kristian
                  • indresh malik
                    Hi Philippe, May be i didnt understand your mail in totality, can you please elaborate what are the issues with APP? We are planning to start a new project
                    Message 9 of 15 , May 29, 2012
                      Hi Philippe,
                      May be i didnt understand your mail in totality, can you please elaborate what are the issues with APP?

                      We are planning to start a new project exposing REST interface and use APP/ATOM feeds for notifications.

                      Appreciate your help!

                      Thanks in advance,
                      Indresh


                      From: Philippe Rathé <prathe@...>
                      To: Kristian Rink <kawazu428@...>
                      Cc: Rest List <rest-discuss@yahoogroups.com>
                      Sent: Tuesday, 29 May 2012 11:39 PM
                      Subject: Re: [rest-discuss] ATOM Pub vs. JSON vs. ...?

                       
                      Hi Kristian,

                      how could be atompub dead? People are just starting to understand
                      REST, how could someone choose atompub when he doesn't understand
                      REST?

                      I'm starting to work on a side project that make uses of APP. I also
                      noticed that it wasn't trendy. But when I realize
                      the reasons were that nobody cares about interoperability and
                      hypermedia driven application state,
                      then my fear disappeared because I care. XML may be less trendy than
                      JSON, that was I used to think. But I found my trend: XQuery in the
                      backend and a native XML database, storing my feeds as-is.

                      I felt that working with APP could be a good knowledge investment.
                      That was a decision that came from my heart first. I recognized
                      something strong in it.

                      Good luck!

                      On Tue, May 29, 2012 at 9:23 AM, Kristian Rink <kawazu428@...> wrote:
                      > Folks;
                      >
                      > I am at the moment into trying to choose a data format / representation
                      > to use for building a RESTful web service which should allow for reading
                      > and writing resources, which should be accessible using "standard" tools
                      > as well as using a dedicated programming API and which should as much as
                      > somewhat possible rely upon existing open standards.
                      >
                      > After doing some reading, I came across Atom and APP as it seems in many
                      > possible ways provide sane and stable solutions for problems at hand
                      > (including things like "workspaces", "feeds", "entries", dealing with
                      > service and category descriptions, dealing with textual and binary
                      > content, dealing with extensibility and stuff like OpenSearch and the
                      > like).
                      >
                      > In many ways, so far it seems the perfect match, however it right now
                      > (at least for me) suffers from a particular shortcoming: I am not really
                      > sure whether it's a technology or a standard to "last". Doing some
                      > reading on that, I rather quickly stumbled across articles pointing out
                      > that "AtomPub has failed" and "AtomPub is basically dead", suggesting
                      > that everyone else uses JSON based REST services right now, eventually
                      > pointing out that even the Google GData services are considered "legacy"
                      > and replaced by different approaches right now. On the other hand I
                      > don't really see what could replace Atom or especially AtomPub talking
                      > about providing a given data structure, a data and service semantics to
                      > allow for read/write interactions with a service in a somewhat sane,
                      > standard way.
                      >
                      > So to ask: If you were about to start a new RESTful project supposed to
                      > work with existing "standard" tools, what kind of data representation
                      > would you choose? Would you still go for Atom / AtomPub? Would you
                      > rather use some kind of JSON+HTTP? Something completely else?
                      >
                      > Thanks in advance for any input,
                      > Kristian
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >


                    • Kristian Rink
                      Hi Philippe; ... Well yes; yet I see people who deal with REST hardly dealing with Atom / APP. Most of the times indeed it ends up being some proprietary XML
                      Message 10 of 15 , May 30, 2012
                        Hi Philippe;


                        Am 29.05.2012 20:09, schrieb Philippe Rathé:
                        > how could be atompub dead? People are just starting to understand
                        > REST, how could someone choose atompub when he doesn't understand
                        > REST?

                        Well yes; yet I see people who deal with REST hardly dealing with Atom /
                        APP. Most of the times indeed it ends up being some proprietary XML or,
                        more likely, some JSON media type being considered "better suited", less
                        overhead to deal with, easier to deliver custom data structures. What
                        they don't usually say (or see, for that matter) is that, ultimately,
                        again it ends up with systems which seem somewhat tightly coupled,
                        JavaScript code in the browser or (even worse) external applications
                        depending upon a custom data structure which might or might not be
                        required to undergo more or less fundamental changes all along the way.
                        From that point of view, I still consider Atom / APP a good thing
                        because it provides a bit more standards-based convention on how to
                        handle things in a portable, interoperable way. So, at the very least I
                        hope some more of its concepts will be likely to make it into things
                        like HAL, Collection+JSON, ... - or concepts derived from these make it
                        into a successor to the current Atom / APP specs if there are any. :)

                        Cheers,
                        Kristian
                      • Philippe Rathé
                        Hi Indresh, sorry if I wasn t clear. My intention was not to find issues to APP. I wanted to tackle the fact that APP was not trendy because the reason that
                        Message 11 of 15 , May 30, 2012
                          Hi Indresh,

                          sorry if I wasn't clear. My intention was not to find issues to APP. I wanted to tackle the fact that APP was not trendy because the reason that makes APP awesome is the part in REST that is misunderstood. APP uses XML which sounds old for some. At least it is true in my entourage, which is mainly composed of young web developers. That is a constatation, but personally I would advocates APP, but I haven't work enough with it yet.

                          If in your case you want to publish notifications, maybe you should consider only using Atom instead of AtomPub?

                          In my case, I wasn't sure if APP was the right choice. But trying to express it within the constraints of APP just opened new horizon. I preferred to keep going with APP because of the  properties it induces in my architecture. Instead of bending the protocol to what I thought was my needs, I decided to harmonize with it by slightly revising my "needs".

                          On Wed, May 30, 2012 at 2:03 AM, indresh malik <malik_indresh@...> wrote:
                          Hi Philippe,
                          May be i didnt understand your mail in totality, can you please elaborate what are the issues with APP?

                          We are planning to start a new project exposing REST interface and use APP/ATOM feeds for notifications.

                          Appreciate your help!

                          Thanks in advance,
                          Indresh


                          From: Philippe Rathé <prathe@...>
                          To: Kristian Rink <kawazu428@...>
                          Cc: Rest List <rest-discuss@yahoogroups.com>
                          Sent: Tuesday, 29 May 2012 11:39 PM
                          Subject: Re: [rest-discuss] ATOM Pub vs. JSON vs. ...?

                           
                          Hi Kristian,

                          how could be atompub dead? People are just starting to understand
                          REST, how could someone choose atompub when he doesn't understand
                          REST?

                          I'm starting to work on a side project that make uses of APP. I also
                          noticed that it wasn't trendy. But when I realize
                          the reasons were that nobody cares about interoperability and
                          hypermedia driven application state,
                          then my fear disappeared because I care. XML may be less trendy than
                          JSON, that was I used to think. But I found my trend: XQuery in the
                          backend and a native XML database, storing my feeds as-is.

                          I felt that working with APP could be a good knowledge investment.
                          That was a decision that came from my heart first. I recognized
                          something strong in it.

                          Good luck!

                          On Tue, May 29, 2012 at 9:23 AM, Kristian Rink <kawazu428@...> wrote:
                          > Folks;
                          >
                          > I am at the moment into trying to choose a data format / representation
                          > to use for building a RESTful web service which should allow for reading
                          > and writing resources, which should be accessible using "standard" tools
                          > as well as using a dedicated programming API and which should as much as
                          > somewhat possible rely upon existing open standards.
                          >
                          > After doing some reading, I came across Atom and APP as it seems in many
                          > possible ways provide sane and stable solutions for problems at hand
                          > (including things like "workspaces", "feeds", "entries", dealing with
                          > service and category descriptions, dealing with textual and binary
                          > content, dealing with extensibility and stuff like OpenSearch and the
                          > like).
                          >
                          > In many ways, so far it seems the perfect match, however it right now
                          > (at least for me) suffers from a particular shortcoming: I am not really
                          > sure whether it's a technology or a standard to "last". Doing some
                          > reading on that, I rather quickly stumbled across articles pointing out
                          > that "AtomPub has failed" and "AtomPub is basically dead", suggesting
                          > that everyone else uses JSON based REST services right now, eventually
                          > pointing out that even the Google GData services are considered "legacy"
                          > and replaced by different approaches right now. On the other hand I
                          > don't really see what could replace Atom or especially AtomPub talking
                          > about providing a given data structure, a data and service semantics to
                          > allow for read/write interactions with a service in a somewhat sane,
                          > standard way.
                          >
                          > So to ask: If you were about to start a new RESTful project supposed to
                          > work with existing "standard" tools, what kind of data representation
                          > would you choose? Would you still go for Atom / AtomPub? Would you
                          > rather use some kind of JSON+HTTP? Something completely else?
                          >
                          > Thanks in advance for any input,
                          > Kristian
                          >
                          >
                          > ------------------------------------
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          >



                        • Eric J. Bowman
                          ... Spoken like someone who understood Roy s thesis. What s perfect may not be what s best. And, what already has high cache retention provides immediate
                          Message 12 of 15 , May 30, 2012
                            Kristian Rink wrote:
                            >
                            > Well actually, despite knowing there actually always will be some
                            > differences in "mapping" a custom data semantics to an existing one,
                            > I figured out that, in our given use case, the concepts of Atom and
                            > APP both fit better than any other approach I found so far, and, then
                            > again, seem to be backed by sufficient support (frameworks,
                            > documentation, tools out there) to eventually provide a reliable
                            > foundation being a "primary representation" in a prototype system
                            > that doesn't want to come up with a custom / proprietary API which
                            > essentially wouldn't do much more than re-inventing things like
                            > workspaces, feeds, entries, categories (one of the things about Atom
                            > that definitely got me enthusiastic about it when I started dealing
                            > with it) or representations accepted when POSTing things to a certain
                            > resource.
                            >

                            Spoken like someone who understood Roy's thesis. What's perfect may
                            not be what's best. And, what already has high cache retention provides
                            immediate benefit that's unlikely to diminish, which newer options
                            won't be able to equal until some nebulous point in the future. The
                            bandwagon may have passed Atom by, but I've never heard of it being de-
                            allowed on intermediaries already configured for it; thus it is neither
                            obsolete, nor without its advantages.

                            -Eric
                          • Eric J. Bowman
                            ... Heheh... don t get me started. ;-) I still think this is the most important, and least-understood, concept in all of REST: The trade-off, though, is
                            Message 13 of 15 , May 30, 2012
                              Kristian Rink wrote:
                              >
                              > Am 29.05.2012 20:09, schrieb Philippe Rathé:
                              > > how could be atompub dead? People are just starting to understand
                              > > REST, how could someone choose atompub when he doesn't understand
                              > > REST?
                              >
                              > Well yes; yet I see people who deal with REST hardly dealing with
                              > Atom / APP. Most of the times indeed it ends up being some
                              > proprietary XML or, more likely, some JSON media type being
                              > considered "better suited", less overhead to deal with, easier to
                              > deliver custom data structures. What they don't usually say (or see,
                              > for that matter) is that, ultimately, again it ends up with systems
                              > which seem somewhat tightly coupled, JavaScript code in the browser
                              > or (even worse) external applications depending upon a custom data
                              > structure which might or might not be required to undergo more or
                              > less fundamental changes all along the way.
                              >

                              Heheh... don't get me started. ;-) I still think this is the most
                              important, and least-understood, concept in all of REST:

                              "The trade-off, though, is that a uniform interface degrades
                              efficiency, since information is transferred in a standardized form
                              rather than one which is specific to an application's needs. The REST
                              interface is designed to be efficient for large-grain hypermedia data
                              transfer, optimizing for the common case of the Web, but resulting in
                              an interface that is not optimal for other forms of architectural
                              interaction."

                              If you can model your system as one of hypertext documents, then you
                              don't need to make design tradeoffs in the name of less overhead, which
                              tend to negate the benefits of REST. So, I say go for it with Atom.

                              Maybe I'm just grumpy because yet another website I frequent now
                              features a broken back button, paging back through script after script
                              until finally, on the 4th or 5th click, user intent is finally
                              respected. Or, because I can no longer right-click Google results to
                              copy an URL, or any number of proliferating faults which break the Web
                              by going against the "natural" architecture which are making it *less*
                              usable and accessible, thanks to gratuitous use of JS.

                              -Eric
                            • Eric J. Bowman
                              ... Also sounds like someone who understood Roy s thesis. Although I d say it s more about designing your system as hypertext documents, rather than Atom/APP
                              Message 14 of 15 , May 30, 2012
                                Philippe Rathé wrote:
                                >
                                > In my case, I wasn't sure if APP was the right choice. But trying to
                                > express it within the constraints of APP just opened new horizon. I
                                > preferred to keep going with APP because of the properties it
                                > induces in my architecture. Instead of bending the protocol to what I
                                > thought was my needs, I decided to harmonize with it by slightly
                                > revising my "needs".
                                >

                                Also sounds like someone who understood Roy's thesis. Although I'd say
                                it's more about designing your system as hypertext documents, rather
                                than Atom/APP specifically; working within the idiom of REST should
                                result in a system where media type is a bike-shed color which can be
                                content-negotiated.

                                -Eric
                              • Kristian Rink
                                Hi Eric, *; and thanks a bunch for your feedback. Well yes I read most of Roy s thesis and I certainly hope I understood some of the principles and ideas
                                Message 15 of 15 , May 30, 2012
                                  Hi Eric, *;

                                  and thanks a bunch for your feedback. Well yes I read most of Roy's
                                  thesis and I certainly hope I understood some of the principles and
                                  ideas outlined there. ;)

                                  Anyway:

                                  Am 30.05.2012 18:10, schrieb Eric J. Bowman:
                                  > "The trade-off, though, is that a uniform interface degrades
                                  > efficiency, since information is transferred in a standardized form
                                  > rather than one which is specific to an application's needs. The REST
                                  > interface is designed to be efficient for large-grain hypermedia data
                                  > transfer, optimizing for the common case of the Web, but resulting in
                                  > an interface that is not optimal for other forms of architectural
                                  > interaction."

                                  Well, off-heart I guess we're not "traditional" hypermedia, we couldn't
                                  be less than that. We live off providing hosted, managed document
                                  management services for construction sites. However, I found that in
                                  many respects hypermedia concepts apply to the way we keep track of our
                                  document structures, as well. There are different customer projects.
                                  Workspaces. There are different groups of documents (drawings, photo
                                  documentation, lists, ...) inside each project (feeds), each of them
                                  allow for read/write access, though the latter usually limited to
                                  certain media types (PDF/HPGL/DWF for drawing layouts, JPG for images,
                                  PDF for virtually everything else). We have to keep track of what we see
                                  the "content" of a document (structured key/value metadata) and 1..n
                                  alternate representations (like a drawing which we have to keep three
                                  equivalent files of - HPGL, PDF, DWF). We have human-readable summaries
                                  (usually used by humans in order to tell what kind of document it is),
                                  creation / change dates, we have authors and different versions and the
                                  whole load. We have documents mainly sorted by key/value attributes,
                                  values being based upon predefined catalogs. Atom categories. That's
                                  what we eventually got. We need, in most cases, data exchange with
                                  systems which are "external" from our point of view. Document management
                                  installations at our customers sites. Competing application service
                                  providers. In all cases, it eventually boils down to transfering
                                  document content (metadata + files) periodically, polling and fetching
                                  what is new.

                                  I spent less than a few hours late one evening diving through some
                                  articles on Atom and repeatedly saw our use cases covered rather well by
                                  what Atom and APP provides. No, we're not a weblog provider or a news
                                  aggregator, but in some ways Atom and APP seems to make sense
                                  technically. Sure, it partially _is_ mapping our stuff to Atom/APP, but
                                  in the end we, well, end up with an external interface relying upon
                                  well-known technologies adhering to well-known semantics rather than
                                  re-inventing the same wheel in a slightly different way in SOAP like so
                                  many does. I then and now enjoy using SOAP, same as I did using CORBA
                                  before, but for this kind of purpose (exchanging information between
                                  different sites where anything else than the systems being loosely
                                  coupled is totally illusionary), things just get overly painful while
                                  manually crafting a custom media type. Did this using JSON in an early
                                  prototype, and learnt enough off this to want it really done with
                                  standards used more widespread when going productive. So far, it seems
                                  Atom/APP as primary media type, backed by HAL+JSON or the like as an
                                  alternative, seems a sane way here.


                                  > Maybe I'm just grumpy because yet another website I frequent now
                                  > features a broken back button, paging back through script after script
                                  > until finally, on the 4th or 5th click, user intent is finally
                                  > respected.

                                  Know what you mean. Then and now was hoping this behaviour would
                                  eventually be gone one day, but it seems it's still here to stay. :/

                                  Cheers,
                                  Kristian
                                Your message has been successfully submitted and would be delivered to recipients shortly.