mikekelly / hal-browser

An API browser for the hal+json media type
MIT License
835 stars 157 forks source link

_embedded resource with curie namespace not rendering in HAl browser ,gives error in uri.min.js #62

Closed gauravbrills closed 9 years ago

gauravbrills commented 9 years ago

Hi I am invoking my service like http://localhost:8080/foos?page=1&size=1 from HAL browser which give me an output like

{
  "_links" : {
    "first" : {
      "href" : "http://localhost:8080/foos?page=0&size=1"
    },
    "prev" : {
      "href" : "http://localhost:8080/foos?page=0&size=1"
    },
    "self" : {
      "href" : "http://localhost:8080/foos"
    },
    "next" : {
      "href" : "http://localhost:8080/foos?page=2&size=1"
    },
    "last" : {
      "href" : "http://localhost:8080/foos?page=81&size=1"
    }
  },
  "_embedded" : {
    "hf:foos" : [ {
      "name" : "comsi",
      "_links" : {
        "self" : {
          "href" : "http://localhost:8080/foos/319001"
        },
,        "hf:foo" : {
          "href" : "http://localhost:8080/foos/8445"
        } ,
      "curies" : [{"href": "/alps/{rel}",
"name":"hf",
"templated": true}
]
      }
    } ]
  },
  "page" : {
    "size" : 1,
    "totalElements" : 82,
    "totalPages" : 82,
    "number" : 1
  }
}

the same does nto render and gives me an error Uncaught Error: URNs do not have any generally defined hierarchical components in console can anyone let me know what I am doing wrong as my api follows hal .The same works fine without curie namespaces in the embedded section seems to be a bug with the Uri.js

UPDATE @olivergierke curies are coming but inside the _embedded resource as u have also said that seems to cause the issue.Have updated the spring data ticket https://jira.spring.io/browse/DATAREST-626 with the response

gauravbrills commented 9 years ago

also is it hf:foo which is causing the issue checked in chrome that gives an error as it treats hf as the urn . Also it seems to be an error with curie namespaces as without the curie namespace hf things work well any idea @mikekelly or @olivergierke .I am rendering it via spring data rest

odrotbohm commented 9 years ago

This is not a browser bug, but the representation missing the curies. I think we fixed a few bus in that area in the recent releases. You might wanna check you use the latest and report a bug in our JIRA if the representation still looks the same.

gauravbrills commented 9 years ago

I am as of now using Gosling-BUILD-SNAPSHOT</spring-data-releasetrain.version> seems that should be the latest .OK will report in the Jira in that case .One more issue there was related to me getting duplicate self links which I had as of now posted on Stackoverflow http://stackoverflow.com/questions/31538048/getting-duplicate-link-of-resource-entity-in-spring-data-rest .Thanks

mikekelly commented 9 years ago

thanks for clearing this up @olivergierke

odrotbohm commented 9 years ago

@mikekelly - Thinking twice about this, isn't what's shown above valid HAL and thus should work in the browser. I agree that the curies could be listed in the root _links block as this would prevent them from occurring multiple times. Still hf:foo should be resolvable, shouldn't it?

gauravbrills commented 9 years ago

@mikekelly @olivergierke can the issue be reopened if this is a browser issue (if a consensus has bee reached).So then I shall close the corresponding issue raised in the spring data rest jira https://jira.spring.io/browse/DATAREST-626.

odrotbohm commented 9 years ago

I overhauled the curie support in Spring HATEOAS so that should be resolved no. About to be released with 0.19 and Spring Data REST 2.4.0 GA in a few days respectively.

drdamour commented 8 years ago

@mikekelly i don't think CURIES should be required by hal browser...maybe sometimes we haven't yet got around to them :( and now we can't display our HAL in latest hal browser cause it is requireing curies