riskfirst / riskfirst.hateoas

Powerful HATEOAS functionality for .NET web api
MIT License
78 stars 25 forks source link

A common standard needs to be agreed upon #25

Closed dnikolovv closed 5 years ago

dnikolovv commented 5 years ago

If you look at the examples in the readme, you will see that the link names (e.g. self) are different from the link relations (the rel tag).

{
   id:1,
   someOtherField: "foo",
   _links : {
    self: {
      rel: "MyController\GetModelRoute",
      href: "https://api.example.com/my/1"
      method: "GET"
    },
    all: {
      rel: "MyController\GetAllModelsRoute",
      href: "https://api.example.com/my"
      method: "GET"
    },
    delete: {
      rel: "MyController\DeleteModelRoute",
      href: "https://api.example.com/my/1"
      method: "DELETE"
    }
  }
}

This works okay but doesn't adhere to the Hypertext Application Language (HAL) standard.

Quoting the Wikipedia article - Links have a target URI, as well as the name of the link (referred to as 'rel'). However, the concept of a link name and its rel are separate in the current implementation.

If we wanted to use XML instead of JSON (as mentioned in this issue) we don't know what approach to take.

In most examples (e.g. https://tools.ietf.org/html/draft-michaud-xml-hal-02#section-6) the value of the rel tag is what we would have as a link name in the JSON format.

<resource rel="self" href="/orders">
    <link rel="next" href="/orders?page=2"/>
    <link rel="find" href="/orderse{/id}" templated="true"/>
</resource>

This is probably going to be a major change, bumping the current version to 4.0, but it needs to be decided.

jamiecoh commented 5 years ago

I'm a bit torn on this issue. In general I have no issue with a major version bum if it makes a better library, but adopting an expired "standard" for the sake of it, without clear benefit I do have a bit of an issue with.

In the JSON implementation I wanted the key to be the link name so developers could easily interact with it when parsed back to a javascript object.

I never really considered an XML implementation (mainly as I never needed it) but I fail to see what the problem is with:

<resource rel="self" href="/orders">
    <link rel="next" href="/orders?page=2"/>
    <link rel="find" href="/orders{/id}" templated="true"/>
</resource>

(ie do you need the controller detail at all? maybe that was a mistake in the JSON implementation).

Basically, can you re-iterate what the problem you're trying to solve actually is?

dnikolovv commented 5 years ago

The problem was that you couldn't serialize to XML without losing the current rel tags.

If you're fine with the suggested XML template, I may tinker with the current implementation a bit to implement it? (as per this issue)

Let me know if that works for you.

jamiecoh commented 5 years ago

By all means have a ticker, and submit a PR if appropriate. Happy to take submissions