Re: User Hypermedia format
Matt McClure <[email protected]> Tue, 4 Mar 2014 12:23:28 -0500
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <[email protected]> |
Mike, > On Feb 28, 2014, at 2:41 PM, mike amundsen <[email protected]> wrote: > > only those pre-built to understand what's already coming would be able to use that representation. > > of course, this assumes that the idea of existing Uber clients being able to read/process/display your data w/o additional custom coding is even a value for you. it may not be. Right. Good points. And it makes me think we could make the conversation less theoretical and more concrete if we turned our attention to what clients and servers will be able to do with Uber without deeper knowledge of data payloads. Do you have some implementation underway? > Now, to back up a bit. > > 1) is this really about programmer optimization? id yes, a few bits of code that translates the internal data into Uber is not a big deal and could solve that problem. Maybe it's a local optimization, but IME, many programmers will not take that step. If it were in a library that would help. I'm imagining passing an arbitrary object to the Uber library and getting an escaped string representation suitable as "value" data out. > 2) is this about payload size? i don't think uber adds much weight at all here (the JSON flavor is certainly more compact than the XML one). and when you're talking about 180,000 data points. that's a pretty big chunk of data anyway. you're free to use compression on the outbound with will greatly reduce the added weight since repeated chars compress very nicely. Without incentives or constraints, IME, many developers would skip the compression step. If you're in control of both clients and servers in your system you can use convention to ensure compression. But it seems we're aiming at a format for distributed development. > 3) finally, what format are you using now? have you looked at HAL? it is designed to host arbitrary objects in a wrapper. I'd be interested to see some comparisions (custom format, HAL, Uber) not just of size of the representation but also the size of the compressed response and the cost to process (surely the Uber will be the most costly to process, right?) Indeed, we are using HAL. What you suggest would be good tests. Matt