feat: add OutgoingRequestInterface

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?

[kenjis]

Description
See #6573, #4356

• add OutgoingRequest
• add OutgoingRequestInterface
• CURLRequest extends OutgoingRequest
• Request extends OutgoingRequest
• RequestInterface extends OutgoingRequestInterface

http://www.plantuml.com/plantuml/uml/ZP1TQWCX58NVNSKX2-XJ5n38IuMKbf0kGEoTGUhFLAzGADrxnQOIbCpaRPXpplUf-yGgSdPMB4f_g9cmEyZ77Ru501ZF52Ub2S-KKadb_uykViay1-Fd4trcIjnge2yc_vwszhTsDy6Y0hHLgR5Xt6B9aUTHrze3iPb6oYWVQJsbcrpJrguWlGvkE5JRrAOFJE2m84nzl-Q0yZ2N0F52caB4q_dy-b0x1Levr-x3KTwhRTKjOock2DzEnurtwyrrCwZ3twYfE-MFs9VlxEml

@startumlpackage"CI4" {
 interfaceMessageInterface interfaceOutgoingRequestInterfaceextendsMessageInterface interfaceRequestInterfaceextendsOutgoingRequestInterface classMessageimplementsMessageInterface classOutgoingRequestextendsMessageimplementsOutgoingRequestInterfacenotetopofOutgoingRequest
an outgoing request.
end note classRequestextendsOutgoingRequestimplementsRequestInterface classIncomingRequestextendsRequestnotetopofIncomingRequest
an incoming request for HTTP.
end note classCLIRequestextendsRequestnotetopofCLIRequest
an incoming request for CLI.
end note classCURLRequestextendsOutgoingRequest
}
@enduml

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[MGatner]

I'm not sure if you implemented it this way because of the restrictions in our current HTTP layer, but the inheritance path for requests is confusing. What is restricting us from making Request a common base for both Incoming and Outgoing, and those not being in the same path?

[kenjis]

PSR-7: MessageInterface > RequestInterface (outgoing) > ServerRequestInterface (incomming)
This PR: MessageInterface > OutgoingRequestInterface (outgoing) > RequestInterface (incomming)

What is restricting us from making Request a common base for both Incoming and Outgoing

CI4's Request is incomming request.

[MGatner]

Wow you are totally right! TIL an incoming request is actually an outgoing request with some extra methods.

So next question... why the new class? If we already have Message > Request > IncomingRequest, what is stopping us from making Request into the equivalent of OutgoingRequest? (sorry if this is obvious, it is very hard to flip between interfaces on mobile)

[kenjis]

what is stopping us from making Request into the equivalent of OutgoingRequest?

The reason for adding the new class is to make as few changes as possible.

RequestInterface is incoming request in CI4.
If we change Request to outgoing request, it seems better to change RequestInterface to outgoing request.
Then we need to add IncommingRequestInterface.

Do you mean like this?
MessageInterface -> Message
OutgoingRequestInterface -> Request
RequestInterface -> IncommingRequest

[MGatner]

I'm with you now, took me a little bit. The structure and names are confusing, but that's not your fault. I would like to look at this one more time on desktop, but generally I think it is a good direction and you should feel free to proceed with the docs.

[kenjis]

Added changelog.

[MGatner]

I think we're there! I would like one other set of eyes here. @paulbalandan or @samsonasik or @iRedds ?