Return-Path: X-Original-To: link-relations@ietfa.amsl.com Delivered-To: link-relations@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560E41A8997 for ; Sat, 15 Aug 2015 06:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNNWMXa4cELK for ; Sat, 15 Aug 2015 06:05:32 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19A01A895C for ; Sat, 15 Aug 2015 06:05:31 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so58941019lbb.3 for ; Sat, 15 Aug 2015 06:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=B4NJ0fAKxp5pCfsFHKFzfhyPTMXqzCajlq8S2lTo/JA=; b=IEIRP6nHx1v+1RRWCRx/a6z4eZUUHQ29KKxLy4xTcUyFUQ1Gov64n0OIJwoEOL9uRr pvRA0xg4M/vqD0coNCcwA18Mx9orQe1LeFjwUOEif0wvI+ay43EQQF6fqpBu78fP+eCM 9JzapJ6VtdufKgNmJBnDixXzBK0uFqk02AxTC0ovj+g/nbfT9LiTZWZjjVYyldhOcxq5 pi9SyAjYEQM+/XKFM2FXPrPsQQ0TLiB1aM0BA4U5JgPd2O5S+E1kBI1glF01KA9/MO5x UQYRf0R59Xr10dSOGTGqtgEPNjbsL4z9QqTENAT/EqIQvC8oCR6RXqueLfRYtxCo7LZs m4TA== X-Received: by 10.152.2.200 with SMTP id 8mr32516220law.115.1439643930184; Sat, 15 Aug 2015 06:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.118.71 with HTTP; Sat, 15 Aug 2015 06:05:10 -0700 (PDT) In-Reply-To: References: From: Mike Kelly Date: Sat, 15 Aug 2015 14:05:10 +0100 Message-ID: Subject: Re: Link relation types for non-GET links To: Klaus Hartke Content-Type: multipart/alternative; boundary=089e0112c2e00fd506051d593967 Archived-At: Cc: link-relations@ietf.org X-BeenThere: link-relations@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 13:05:33 -0000 --089e0112c2e00fd506051d593967 Content-Type: text/plain; charset=UTF-8 Fair enough. It's worth bearing in mind the cache lifetime of the link rel descriptions are likely to be relatively high compared to the resources themselves; so the indirection could potentially reduce the size of the responses as well as metadata noise in the responses. But if you need/want this information inline, then you can attach it as a properly to the given link object. Cheers, M On Sat, Aug 15, 2015 at 1:27 PM, Klaus Hartke wrote: > Mike Kelly wrote: > > You can use a standard HAL link and a link relation if you ensure the > link > > relation is a URL which can be dereferenced to retrieve a > machine-readable > > description of the methods and messages that are possible for that link. > > Just think of it as machine readable link relation documentation. > > That's an interesting idea. It basically adds a level of indirection, > which should be useful if many links have the same machine-readable > description of possible methods and payloads. However, I think I'd > prefer including that description directly at the link, so a client > does not have to dereference a URL to understand the link semantics. > > Klaus > -- Mike http://twitter.com/mikekelly85 http://github.com/mikekelly http://linkedin.com/in/mikekelly123 --089e0112c2e00fd506051d593967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair enough. It's worth bearing in mind the cache life= time of the link rel descriptions are likely to be relatively high compared= to the resources themselves; so the indirection could potentially reduce t= he size of the responses as well as metadata noise in the responses.
But if you need/want this information inline, then you can att= ach it as a properly to the given link object.

Che= ers,
M

On Sat, Aug 15, 2015 at 1:27 PM, Klaus Hartke = <hartke@tzi.org&= gt; wrote:
Mike K= elly wrote:
> You can use a standard HAL link and a link relation if you ensure the = link
> relation is a URL which can be dereferenced to retrieve a machine-read= able
> description of the methods and messages that are possible for that lin= k.
> Just think of it as machine readable link relation documentation.

That's an interesting idea. It basically adds a level of indirec= tion,
which should be useful if many links have the same machine-readable
description of possible methods and payloads. However, I think I'd
prefer including that description directly at the link, so a client
does not have to dereference a URL to understand the link semantics.

Klaus



--
Mike

http://twitter.com/mikekelly85
http://github.com/mikek= elly
http://linkedin.com/in/mikekelly123
--089e0112c2e00fd506051d593967--