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

Re: [rest-discuss] ATOM Pub vs. JSON vs. ...?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.