Re: ATOM Pub vs. JSON vs. ...?

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