On 02.07.2012, at 17:53, Jens Alfke wrote: > > On Jul 2, 2012, at 5:08 AM, Andreas Grosam wrote: > >> Well, embedding an image encoded in base64 in a JSON document is not that >> "RESTful" anyway. > > Sure it is. Plenty of REST-based APIs do this sort of thing (CouchDB and Atom > both come to mind.) The REST principles don't dictate any particular transfer > format for data, and allow for aggregate URLs that represent multiple > resources.
Well, I should have been more accurate what I actually meant by this: For instance, when we retrieve a list of things (not just images) or some container object which contains an image - we should NOT return those objects inlined which itself can be identified by its own URI - but instead providing the URI. Simply because this better implements the idea behind REST. There is actually a statement from Roy Fielding himself, who suggest (or better dictates) this course of action. Please read <http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven>, and countless discussions about the pros and cons, and as well HATEOAS <http://en.wikipedia.org/wiki/HATEOAS> In practice however, this is not always optimal for all applications. In case of images though, we can easily see that returning an URI as the result of the very first request is likely the better idea, than returning the whole staff at once. The application can chose later to retrieve any more detail information - using the URIs provided in the first request. But eventually, we may need to retrieve the image data through its URI - and this may be accomplished without using JSON, and still being completely RESTful. > >> There are third party JSON libraries which are capable to customize the >> mapping, though. For instance, it might suffice to implement a method for a >> Category for NSImage to accomplish this (JPJson library uses this approach >> for example). That way, you can serialize a hierarchy of Foundation objects >> which contains a NSImage - no matter where this occurs in the tree. > > It's certainly possible to do that, but it doesn't seem like a good idea to > me, because there's no unambiguous data format associated with an image. Even > choosing between the two most obvious formats (JPEG and PNG) involves a > decision about trade-offs between fidelity loss and file size. Thus, you *customize* the mapping - that is, you handle this case application specific. Of course, this shall be in accordance to the "protocol" - the API. > I would instead have the app itself decide how to encode the image as data, > and then set up an unambiguous mapping from NSData to base64-encoded JSON > strings. (Of course on the other end it's trickier because how does the > decoder know what strings should be decoded to NSData and which should be > left alone? YAML has type annotations that provide for this, but JSON > doesn't.) Alternatively, you could do this: Instead of defining how an NSImage would serialize itself into JSON, you may define how the "owner" of that said image object would serialize itself into a JSON. Since it is assumed that this kind of object has enough context information, it can select the right actions: @interface Person { @propery (NSString*) name; @propery (NSString*) email; @property (NSImage*) image; } A custom object would usually serialize itself as a JSON Object (aka NSDictionary). How this can be actually accomplished in code, certainly depends on the JSON library - and whether this is possible at all with this library. Furthermore, the object shall of course serialize itself according the API specified for this kind of Web-service. Basically, in JPJson library you would need to implement a method for this class Person (either Category or sub-class): - (NSInteger) JPJson_serializeTo:(id<JPJsonStreambufferProtocol>) buffer encoding:(JPUnicodeEncoding)encoding options:(JPJsonWriterOptions)options level:(NSUInteger)level; Within that method, you would serialize the image - if required, or provide a URI. The API may specify all these details. Andreas > > —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
