You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: Server protocol implementation guideline #214
i think it would be useful to add a guideline for a complete server protocol implementation.
After having problems with redirects, which could be quickly resolved by #213, i could not find documentation regarding the (server side) handling of redirects.
My proposal would be to extend the section of the server protocol with a guide about the cases that have to be considered for a complete server side implementation and are not directly related to the unpoly API.
I think a good first step would be adding the redirect strategy Henning shared in #213. I was aware of it as Henning mentioned it to me a little while back, but I hadn't had a chance to look for it in the codebase. Seeing it illustrated as bullet points sets me somewhat at ease for implementation difficulty.
A step-by-step would be perfect)) For those, who are already in the middle of implementing such a protocol the guideline is less useful. They have certain questions, which might not be general to be included in a guideline, but rather should be handled on a case by case basis.
And we, who only think about starting to think about implementing it for our systems, can't suggest what should be in such a guideline.
What are some other things that would have helped you writing your protocol implemention?
I didn't want to make the redirect persistence a requirement for new integrations, as I found it pretty hard to implement for unpoly-rails.
I think a list of headers that need special handling at the server side integration level would make the documentation easier to navigate. A lot of the headers are not directly interesting at the integration level, because they are set by the end-user.
This list could also be sorted by subjective importance. I think _up_method and form handling should be implemented before redirect persistence.
Also more code example would be useful. While there are examples for X-Up-Fail-Target, there are none for the important _up_method. Maybe the relevant code sections of the rails-implementation could be linked as a starting point for new integrations.
I wonder if there's a way we can share a "spec", where we implement an app using our server protocol implementations, and then that spec is run against the app.
Could we extract the Jasmine tests somehow? and would that be useful?
Activity
adam12 commentedon Jul 8, 2021
I think a good first step would be adding the redirect strategy Henning shared in #213. I was aware of it as Henning mentioned it to me a little while back, but I hadn't had a chance to look for it in the codebase. Seeing it illustrated as bullet points sets me somewhat at ease for implementation difficulty.
triskweline commentedon Jul 9, 2021
What are some other things that would have helped you writing your protocol implemention?
I didn't want to make the redirect persistence a requirement for new integrations, as I found it pretty hard to implement for
unpoly-rails.ivangretsky commentedon Jul 9, 2021
A step-by-step would be perfect)) For those, who are already in the middle of implementing such a protocol the guideline is less useful. They have certain questions, which might not be general to be included in a guideline, but rather should be handled on a case by case basis.
And we, who only think about starting to think about implementing it for our systems, can't suggest what should be in such a guideline.
jwaschkau commentedon Jul 14, 2021
I think a list of headers that need special handling at the server side integration level would make the documentation easier to navigate. A lot of the headers are not directly interesting at the integration level, because they are set by the end-user.
This list could also be sorted by subjective importance. I think _up_method and form handling should be implemented before redirect persistence.
Also more code example would be useful. While there are examples for X-Up-Fail-Target, there are none for the important _up_method. Maybe the relevant code sections of the rails-implementation could be linked as a starting point for new integrations.
adam12 commentedon Jul 29, 2021
I wonder if there's a way we can share a "spec", where we implement an app using our server protocol implementations, and then that spec is run against the app.
Could we extract the Jasmine tests somehow? and would that be useful?
triskweline commentedon Jul 30, 2021
The Jasmine specs are just a bunch of static HTML and JS files. Network communication to the server is mocked.