[apps-discuss] json-home: comments and questions on draft 02

Dirk F5R <dirk.f5r@googlemail.com> Wed, 14 November 2012 11:37 UTC

Return-Path: <dirk.f5r@googlemail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0821C21F84E8 for <apps-discuss@ietfa.amsl.com>; Wed, 14 Nov 2012 03:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm3drt-4fWoh for <apps-discuss@ietfa.amsl.com>; Wed, 14 Nov 2012 03:37:05 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39021F84E3 for <apps-discuss@ietf.org>; Wed, 14 Nov 2012 03:37:04 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so344745lbk.31 for <apps-discuss@ietf.org>; Wed, 14 Nov 2012 03:37:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=j5dEdUNgSYC7Qou1oOJn081fOobeOdXn8zYyxZ5pk9w=; b=UDndF5N1al2VKK1is9j4p/MXsLHi0LgSokLadI/88q7Vf9z8yzA8ENZ1e8r8QXzgAd 6/7GM1KCGNfwxfw9SSGM2U5N9LAcxxxL719K/Wluoc20da1uJBqXVi7lRF18pVA3e0is Oeib5jadqZppQuHaYvRT0C4a2gJi+8TBjZzimMw5Zc4bY93FsgSTOMQKQRtHZro1bXfe ByL35YmMdsq8UWLDfU7T6OpRD1FOOtDT0nrDAjtb035zWe3xrmL+PKBkYaKITiQqKnmY LSz3mJ4w//PMLjRZ/uWG9VqZmKblLfuKBEYsXVnlYTb+NATCxZIdayRjxRk8tjhBpWME +hnw==
Received: by 10.112.36.200 with SMTP id s8mr10719607lbj.92.1352893023587; Wed, 14 Nov 2012 03:37:03 -0800 (PST)
Received: from limo3121.local ([62.213.146.106]) by mx.google.com with ESMTPS id d5sm502551lbk.10.2012.11.14.03.37.01 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 03:37:02 -0800 (PST)
Message-ID: <50A38259.4050304@googlemail.com>
Date: Wed, 14 Nov 2012 12:36:57 +0100
From: Dirk F5R <dirk.f5r@googlemail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: apps-discuss@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [apps-discuss] json-home: comments and questions on draft 02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2012 11:37:06 -0000

Hi all, hi Mark,

I had a closer look at 
http://pretty-rfc.herokuapp.com/draft-nottingham-json-home and 
http://tools.ietf.org/html/draft-nottingham-json-home-02 since I also 
absolutely see the need for an API "home page" as well. As a matter of 
fact, the specs I have contributed to at work come with what we call a 
"service document" (I can't help using that term in the remainder of 
this mail). This is only another term for basically the same concept: 
one single entry point into a hypermedia API that reveals links to 
something like top-level resources. The URI to the service document is 
the only thing that needs to be published to client developers, from 
there we strictly follow the HATEOAS principle.

I have a few comments / questions on json-home:

When I look at the json-home draft, it looks to me as if it were 
actually two separate ones. One that deals with the need of a service 
document and how it might look like and one that defines how links 
should look like in JSON. The latter one though is nothing specific to 
the service document but would rather be a general convention. Shouldn't 
this be two separate draft documents?

As to my current perception, I'm also not sure why the service document 
should have a different format or structure than any other document that 
comes back from an API. For instance, if your representations always 
come with an attribute called "links" that hosts explicit links by 
relation types, why should this be different for the service document? 
This leads me to the opinion that it should be defined <somewhere> as a 
requirement that hypermedia APIs must come with a service document but I 
don't necessarily see the need to define a particular format or media 
type for it.

Thanks for listening and happy to read your comments. ;-)

Glück auf!
Dirk