General Description about Working Principles

[vanthome]

I think we need a short description about the working principles of the console.
In my opinion best told with some use cases like these:

UC1 - GET API Documentaion:
1.) Make a request to the given API endpoint
2.) Client detects type ApiDocumentation
3.) Render interactive representation of the documentaion

UC2 - GET Collection/ Paged Collection:
1.) Make a request to the given API endpoint
2.) Client detects type Collection / PagedCollection
3.) Render interactive representation of the collection

UC3 - GET Resource:
1.) Make a request to the given API endpoint
2.) Client detects type Resource
3.) Render interactive representation of the resource

etc.

Also, I propose the following enhancements:

• Refactor Hydra client so that it is independent from Backbone (may later be put into a seperate project)
• Error handling must be better: Notify the user that a response could not be interpreted
• Remove dependency to PHP proxy as the Vocabs should now reside on locations that return proper CORS headers

[lanthaler]

I think we need a short description about the working principles of the console.

Where do you think we need to describe that? In the README? A dedicated documentation? Somewhere else?

In my opinion best told with some use cases like these:

UC1 - GET API Documentaion:
1.) Make a request to the given API endpoint
2.) Client detects type ApiDocumentation
3.) Render interactive representation of the documentaion

UC2 - GET Collection/ Paged Collection:
1.) Make a request to the given API endpoint
2.) Client detects type Collection / PagedCollection
3.) Render interactive representation of the collection

UC3 - GET Resource:
1.) Make a request to the given API endpoint
2.) Client detects type Resource
3.) Render interactive representation of the resource

Who do you see as the target group of these descriptions?

Also, I propose the following enhancements:
• Refactor Hydra client so that it is independent from Backbone (may later be put into a seperate project)
• Error handling must be better: Notify the user that a response could not be interpreted

That's a pretty accurate description of where I would like to get with the HydraConsole. The only problem I have at the moment is time. Unfortunately, I can't push that forward myself in the next couple of weeks. Could you get this started? That would be fantastic.

• Remove dependency to PHP proxy as the Vocabs should now reside on locations that return proper CORS headers

Please also note that the resource rendering currently depends on the (modified) PHP JSON-LD processor.

[vanthome]

I think we could put it in a Wiki here on GH as it is supplementary material.

The target groups are:

• People who want to understand in detail what the Hydra Console can do
• People who want to implement a Hydra based API which is compatible with the Console can use it to learn what Features of Hydra they have to implement

I consider working on this...
Would you mind if I switch the MV* Framework implementation from Backbone to Ember JS?

Regarding the PHP Proxy: Would you mind doing the rendering entirely on the Client?

[lanthaler]

Sorry for the delay Thomas

I think we could put it in a Wiki here on GH as it is supplementary material.

I'm not a big fan of Wikis but we can use it to get this thing started. Depending on how long the document gets, we could perhaps include directly in the README.

The target groups are:
• People who want to understand in detail what the Hydra Console can do
• People who want to implement a Hydra based API which is compatible with the Console can use it to learn what Features of Hydra they have to implement

Makes sense.. a lot of this stuff probably would make sense in the README as proposed above

I consider working on this...

Cool. That would be much appreciated

Would you mind if I switch the MV* Framework implementation from Backbone to Ember JS?

No, I wouldn't mind. What's the advantage of doing so? If everything is properly refactored, there should be very little code left that is affected by the choice of the framework anyway.

Regarding the PHP Proxy: Would you mind doing the rendering entirely on the Client?

Nope, in fact I would prefer it.

[wancharle]

Ps.: sorry my english: i don't speak english!
I think this is important .
i was using the console to learning, but its become complicated... i tried mimic the jsons responses of event-api demo, but i have many mistakes... example: i tried put the code bellow to response of entry point on my server:

{
  "@context": "/hydra/event-api/contexts/EntryPoint.jsonld",
  "@id": "/hydra/event-api/",
  "@type": "EntryPoint",
  "events": "/hydra/event-api/events/"
}

but i have errors...then i figure out this... the response expected by the console is this:

{
    "@context": {
        "__value": "/hydra/event-api/contexts/EntryPoint.jsonld",
        "__activectx": {
            "@base": {},
            "hydra": {
                "@id": "http://www.w3.org/ns/hydra/core#",
                "@reverse": false
            },
            "vocab": {
                "@id": "http://www.markus-lanthaler.com/hydra/event-api/vocab#",
                "@reverse": false
            },
            "EntryPoint": {
                "@id": "http://www.markus-lanthaler.com/hydra/event-api/vocab#EntryPoint",
                "@reverse": false
            },
            "events": {
                "@id": "http://www.markus-lanthaler.com/hydra/event-api/vocab#EntryPoint/events",
                "@reverse": false,
                "@type": "@id"
            }
        }
    },
    "@id": {
        "__iri": "@id",
        "__value": {
            "__orig_value": "/hydra/event-api/",
            "__value": {
                "@id": "http://www.markus-lanthaler.com/hydra/event-api/"
            }
        }
    },
    "@type": {
        "__iri": "@type",
        "__value": {
            "__orig_value": "EntryPoint",
            "__value": {
                "@id": "http://www.markus-lanthaler.com/hydra/event-api/vocab#EntryPoint"
            }
        }
    },
    "events": {
        "__iri": "http://www.markus-lanthaler.com/hydra/event-api/vocab#EntryPoint/events",
        "__value": {
            "__orig_value": "/hydra/event-api/events/",
            "__value": {
                "@id": "http://www.markus-lanthaler.com/hydra/event-api/events/"
            }
        }
    }
}

what is this properties : __value, __orig_value, __activectx etc?

I suppose it's the result of the recursive processing of the original json.But I do not know how I can do this processing in my api. is a different form of serialization json? I've been researching and found that there are different forms (expanded, flatened, framed) but do not know how the console is waiting ...

I'm using node.js and mongo.db on my server. Is there any lib that allows automate this json pre-processing of my api for it to be compatible with your console without the need to add these properties manually? if not there is a lib for node.js to do that ... u have any document or article that explains this pre-PROCESSING the json so I can implement the processor for node.js community.

I thank you for your attention.

[lanthaler]

Good point @wancharle. In 7d1b837 I added a reference to the high-level description of how the HydraConsole works in my dissertation. If you have further questions, feel free to join the Hydra W3C Community Group and post your questions directly to our mailing list. All details can be found here: http://www.hydra-cg.com/#community

[wancharle]

thanks @lanthaler i will go read it!

[lukasgraf]

After searching for the implementation of the extended expansion algorithm for quite a while: It's in the expansion-debug branch of the JsonLD package, starting with aa331099.

[wancharle]

thank you! this helped me a lot.