-
Notifications
You must be signed in to change notification settings - Fork 19
Use constants for directories and add smartykey. #67
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made two comments.
Basically it seems fine except I'm confused by the "Backwards compatible automatic appending of api path" commit. I'm not sure what its trying to accomplish and why the endpoints aren't encapsulated inside the Request
.
src/Request.php
Outdated
@@ -97,7 +97,14 @@ public function setReferer($referer) { | |||
$this->referer = $referer; | |||
} | |||
|
|||
public function setUrlPrefix($urlPrefix) { | |||
public function setUrlPrefix($urlPrefix, $apiPath) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try using a default parameter to keep this function backwards compatible, particularly since its public
.
e.g. public function setUrlPrefix($urlPrefix, $apiPath = "")
src/Sender.php
Outdated
@@ -3,5 +3,5 @@ | |||
namespace SmartyStreets\PhpSdk; | |||
|
|||
interface Sender { | |||
function send(Request $request); | |||
function send(Request $request, $apiPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not understand the need for an $apiPath
parameter. It seems to me whatever endpoint is used should already be encapsulated inside the Request
object when the request is built by the product-specific class. This feels like a leaky abstraction, thus increasing complexity for everything that uses Request
.
Even if $apiPath
remains, we may want to make it an optional parameter to avoid breaking consumers of the methods/interface since they are public--unless we really, really mean to make $apiPath required which it doesn't appear like since there are many defaults of ''
in the PR.
Just as a tangent, you may want to consider creating a constant for the endpoint paths, like/verify
and /lookup
, etc (ie, what is being used as the $apiPath
). Since the endpoint is specific to the product API, using a class constant may be appropriate. That said, in this PR it looked like each endpoint is only referenced once so I'd call it an optional change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The $apiPath
was added to match the functionality of our other sdks. When providing a custom url the PHP sdk requires the endpoint whereas the other sdks only require the base url. So the backward compatible part allows the custom url to include the endpoint or not. The $urlPrefix
isn't available to the buildRequest()
product-specific function so I opted for the send()
method and most of the calls with ''
are tests anyway.
I agree updating the signature to be an optional parameter makes more sense. To your point though this isn't a necessary update so I will default to your judgement if you think it is more complicated/leaky than its worth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the code perspective, I'm good with the implementation changes.
The modification of path behavior in the withUrl
option should be double-checked with backward-compatibility use-case expectations.
Also added backward compatible automatic appending of api path.