Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable Caching #22

Open
kadeatfox opened this issue Apr 14, 2016 · 3 comments
Open

Disable Caching #22

kadeatfox opened this issue Apr 14, 2016 · 3 comments

Comments

@kadeatfox
Copy link

screen shot 2016-04-14 at 11 07 58 am

screen shot 2016-04-14 at 11 08 05 am

Changing the values of the different fields to see how the app itself actually acts, and it will take minutes for the change to actually take effect. It is extremely frustrating, especially when battling the learning curve.

Please also provide more documentation. It would also be nice if there was perhaps another layer of abstraction.

@lanthaler
Copy link
Owner

Could you please elaborate a bit. How do you change “the values of the different fields”. Which fields do you refer to?

Documentation is indeed sorely missing here. In the meantime, you can find a (likely slightly outdated) description of how the console works at http://m.lanthi.com/3gen-web-apis-p171 (PDF). Refactoring this into multiple libraries has been on my to do list for a while by now but I can’t seem to find the necessary time to do so. Help would be highly appreciated.

@kadeatfox
Copy link
Author

Hi @lanthaler,

I apologize for the sparseness in my raised issue. Essentially, I am trying to develop my API around the hydra spec and using the console to verify my results. So far, after weeks of messing around with it when time permits, I still have been unable to successfully get documentation to render.

I would like to raise multiple issues here, but I'll simply elaborate on this one for now:

Basically, after making code changes in my API's auto documentation script, I will refresh the console, input my API's entry point link (which does respond with the proper vocab link header), and the console's response will contain the old values prior to my code change. To verify it isn't something I did, I will hit the same endpoint in my browser and see the updated change. I'll repeat the refresh process in the console, and the old values will still be there, despite being different on a direct response from my browser.

I'm not sure where in the code this is taking place, but it is seriously making me consider abandoning the spec. The overall idea of this sort is thing is quite great, but the implementation, I think needs to be improved. (To no fault of anyone I might add)

I'm curious to know... After reading through your dissertation, It almost seems like the console was a bit of just a proof of concept. A lose quote would be something to the effect of: Developers need to see a way a Generic client can be made to document hydra enabled API's. Perhaps it is time for a more robust Implementation of this concept? A Hydra Console 2.0 with more descriptive error messages to guide would-be-implementors along the learning curve? Or perhaps even an effort to create what you had envisioned, a brand new Generic client that supports Hydra?

Let me please reiterate, both my boss and I strongly endorse your idea. I'm a software Engineer at FOX Networks group and would be interested in coordinating further with you regarding this. Would you be interested in setting up a Conference Call?

@lanthaler
Copy link
Owner

after making code changes in my API's auto documentation script, I will refresh the console, input my API's entry point link (which does respond with the proper vocab link header), and the console's response will contain the old values prior to my code change.

Are you doing that locally on your machine or on the instance running on my website? Did you set up the HTTP caching headers correctly (otherwise the browser caches it)?

the implementation, I think needs to be improved

Fully agreed :-)

It almost seems like the console was a bit of just a proof of concept

That's the case, yes

Perhaps it is time for a more robust Implementation of this concept? A Hydra Console 2.0 with more descriptive error messages to guide would-be-implementors along the learning curve? Or perhaps even an effort to create what you had envisioned, a brand new Generic client that supports Hydra?

Yes, I think it would definitely be time for that. My time is quite limited and I have been mainly trying to drive the specification recently. Would you be willing to contribute to such an effort? If so, the first step would be for you to join the Hydra W3C Community Group (description of the necessary steps to do so). I will then send out a mail to our mailing list to see who else would be interested to join that effort.

Let me please reiterate, both my boss and I strongly endorse your idea. I'm a software Engineer at FOX Networks group and would be interested in coordinating further with you regarding this. Would you be interested in setting up a Conference Call?

That's great to hear. Lets see if we can make this happen without a call (I'm mostly traveling till end of next week)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants