In the definition of a resource we have "All other properties MUST be valid JSON, and represent the current state of the resource.".
This somewhat implies a FULL representation, the original spec says " Content embedded within a *Resource* element MAY be a full, partial, summary, or incorrect representation of the content available at the target URI". Is this a deliberate change or just an oversight?
> In the definition of a resource we have "All other properties MUST be valid
> JSON, and represent the current state of the resource.".
> This somewhat implies a FULL representation, the original spec says "
> Content embedded within a Resource element MAY be a full, partial, summary,
> or incorrect representation of the content available at the target URI". Is
> this a deliberate change or just an oversight?
What is the reasoning for making _links/_link.self optional? That means that a resource may not have a self link, but if it has it's still under _links right?
I'm working on (yet another) ruby implementation, so I have some tests to rewrite :P
On Wed, Jul 4, 2012 at 12:35 AM, locks <rok...@gmail.com> wrote:
> Hi Mike,
> A couple of questions.
> What is the reasoning for making _links/_link.self optional?
One reason would be to make hal use-able as a media type for requests
that create resources. Requring a self link would require a client to
specify a yet-unknown URI.
> That means that a resource may not have a self link, but if it has it's
> still under _links right?
Indeed
> I'm working on (yet another) ruby implementation, so I have some tests to
> rewrite :P
Which tests are those, is this on github? Be great to look at those
changes to get an idea of the impact its had - same goes for anyone
else, please share your pains/thoughts. If this change is too
distruptive, I can always revert it - but I need people's feedback.
On Wednesday, July 4, 2012 7:29:03 AM UTC+1, Mike Kelly wrote:
> On Wed, Jul 4, 2012 at 12:35 AM, locks <rok...@gmail.com> wrote: > > Hi Mike,
> > A couple of questions.
> > What is the reasoning for making _links/_link.self optional?
> One reason would be to make hal use-able as a media type for requests > that create resources. Requring a self link would require a client to > specify a yet-unknown URI.
> > That means that a resource may not have a self link, but if it has it's > > still under _links right?
> Indeed
> > I'm working on (yet another) ruby implementation, so I have some tests > to > > rewrite :P
> Which tests are those, is this on github? Be great to look at those > changes to get an idea of the impact its had - same goes for anyone > else, please share your pains/thoughts. If this change is too > distruptive, I can always revert it - but I need people's feedback.
In my case I was requiring a URI when creating a new resource, and assuming that _links would always be present when parsing a HAL document. Given that and the early state of the library it's easy to update it.
On Wed, Jul 4, 2012 at 2:33 PM, Darrel Miller <darrel.mil...@gmail.com> wrote:
> Does this mean that in the XML variant that the href attribute should
> now be optional also? Therefore the following is valid:
It's not that I have any specific objections to it. It does however,
significantly change the meaning of a hal document. We now support
the notion of representing a non existent resource. That may be an
amazingly clever addition or it may cause untold pain. Only time will
tell, I guess.
It does mean that hal can now be used to do exactly what mnot is doing
with json-problem, because we no longer have the problem of error
resources needing a URI.
When we were talking about the ability to make _links optional in the
JSON variant, I had not put two and two together that it would remove
the identity link also, because in the XML variant embedded links and
the resource link are not tied together.
On Wed, Jul 4, 2012 at 9:39 AM, Mike Kelly <mikekelly...@gmail.com> wrote:
> Hi Darrel,
> The I-D still contains a SHOULD in the recommendations section.
> I take it you are not in favour of this change ?
> Cheers,
> M
> On Wed, Jul 4, 2012 at 2:33 PM, Darrel Miller <darrel.mil...@gmail.com> wrote:
>> Does this mean that in the XML variant that the href attribute should
>> now be optional also? Therefore the following is valid:
On Thu, Jul 5, 2012 at 1:58 AM, Darrel Miller <darrel.mil...@gmail.com> wrote:
> I saw that it is still a SHOULD.
> It's not that I have any specific objections to it. It does however,
> significantly change the meaning of a hal document. We now support
> the notion of representing a non existent resource. That may be an
> amazingly clever addition or it may cause untold pain. Only time will
> tell, I guess.
> It does mean that hal can now be used to do exactly what mnot is doing
> with json-problem, because we no longer have the problem of error
> resources needing a URI.
> e.g.
> <resource >
> <resource rel="http://example.com/probs/out-of-credit" >
> <title>"You do not have enough credits."</title>
> <detail>"Your current balance is 30, but that costs 50."</title>
> <balance>30</balance>
> <account>http://api.example.com/account/12345</account>
> </resource>
> </resource>
> When we were talking about the ability to make _links optional in the
> JSON variant, I had not put two and two together that it would remove
> the identity link also, because in the XML variant embedded links and
> the resource link are not tied together.
Just to be clear: When I proposed making links optional I proposed
that an identity property, 'hal',
be required.
From memory, making an identity link optional wasn't discussed.
> On Wed, Jul 4, 2012 at 9:39 AM, Mike Kelly <mikekelly...@gmail.com> wrote:
>> Hi Darrel,
>> The I-D still contains a SHOULD in the recommendations section.
>> I take it you are not in favour of this change ?
>> Cheers,
>> M
>> On Wed, Jul 4, 2012 at 2:33 PM, Darrel Miller <darrel.mil...@gmail.com> wrote:
>>> Does this mean that in the XML variant that the href attribute should
>>> now be optional also? Therefore the following is valid:
