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
So as we all know from the API standard, there are two types of redirects:
internal redirect (see forward/java, loopback/nodejs, stepfunctions/Lambdas)
external redirect
Internal redirection is mainly done by multithreaded applications as they have a front controller embedded in the api application rather than abstracted to the app server like in single threaded api apps.
Roy Fieldings dissertation talks about the front controller repeatedly as in how the state of the request/response is maintained :
"There must be some controller object that is responsible for
maintaining the system state in order to complete the application requirements."
He even stated in an email to me (after Darrel Miller stated he asked him this question):
I don’t recall hearing that question (nor it’s context), but the term “internal redirect” was created for NCSA httpd (and continued by Apache) to refer to requests internal to the server implementation (like a file include), in contrast to "external redirect" being an HTTP 3xx response message. Hence, there are no internal redirects in HTTP because they aren’t part of HTTP: they are content handlers within some server code. Note that those content handlers might include sub-requests that use HTTP, but those sub-requests are just normal GET requests to obtain content which is then repackaged with an HTTP success or error response.
My example is the custom error pages in Apache when configured as URLs.
And, yes, **of course they exist, but not in HTTP.** I have no idea if that helps or hurts your discussion.
However the problerm lies it seems in the fact you all are only implementing an EXTERNAL REDIRECT which seems to target only single threaded applications like Node.js which are only a partial implementation of the HTTP standard for redirection.
Is this the case with this standard or are you planning to support the HTTP standard fully by implementing internal redirection?
This would be fully compliant with Roy Fieldings dissertation on API's.
Now lets try this a third time (#271 and #261).... and see if you are going to say me AND Roy Fielding are 'making it all up'
The text was updated successfully, but these errors were encountered:
So as we all know from the API standard, there are two types of redirects:
Internal redirection is mainly done by multithreaded applications as they have a front controller embedded in the api application rather than abstracted to the app server like in single threaded api apps.
Roy Fieldings dissertation talks about the front controller repeatedly as in how the state of the request/response is maintained :
"There must be some controller object that is responsible for
maintaining the system state in order to complete the application requirements."
He even stated in an email to me (after Darrel Miller stated he asked him this question):
However the problerm lies it seems in the fact you all are only implementing an EXTERNAL REDIRECT which seems to target only single threaded applications like Node.js which are only a partial implementation of the HTTP standard for redirection.
Is this the case with this standard or are you planning to support the HTTP standard fully by implementing internal redirection?
This would be fully compliant with Roy Fieldings dissertation on API's.
Now lets try this a third time (#271 and #261).... and see if you are going to say me AND Roy Fielding are 'making it all up'
The text was updated successfully, but these errors were encountered: