Closed sandervanhooft closed 6 years ago
The response for OrderEndpoint.get/create/list
includes order lines (lines
).
@ndijkstra Should this be an OrderLineCollection
resource?
It would be a first for this client to include a nested resource(collection) in a response. It would probably require overriding the rest_create
method.
The order lines are in the order response. The order line endpoint is only for canceling an order line
Ok, so no OrderLineCollection
is necessary on the Order
resource?
I'll update the plan above to only include the cancel
method on OrderLine
.
I think that is correct. @Smitsel Can you check if this is ok?
I think it is, take for example the IssuerCollection. These are an include on the methods api. But its rather useful to make them value objects.
This way we can iterate the OrderLineCollection and create cool helper functions like:$orderline->cancel()
.
So please do add them :)
I can also see value for people implementing this library and typehint them for example.
Thanks @Smitsel ! I overlooked the IssuerCollection on the methods api. I'll look into that one for inspiration.
By the way, why are all properties defined explicitly on the resource classes? The tests are passing without. Is this for autocompletion?
Yes it is.
Are there any other relations I should be aware of, like to a customer
entity?
I.e. the word "customer" is used a lot in the order docs, but there seems to be no relationship defined.
I'm assuming there's going to be a Order cancel (delete) api endpoint, right?
I.e.
curl -X DELETE https://api.mollie.com/v2/orders/ord_kEn1PlbGa \
-H "Authorization: Bearer test_dHar4XY7LxsDOtmnkVtjNVWXLSlXsM"
Correct. Docs coming soon ๐
OrderEndpoint ready (see backlog). Had to use some response fixtures and assertion helpers to keep the test file length in check. Reduced it from 1600+ lines to less than 600. Pfew ๐
Had to use some response fixtures and assertion helpers to keep the test file length in check.
Yes, it is very important to remember that tests are software too, and they can massively benefit from abstractions just as the units under test.
@sandervanhooft just noted the incorrect casing of Stdclass
, it should be stdClass
Thanks @holtkamp!
Interestingly though, the tests pass... Nevertheless, I'll convert StdClass
into stdClass
as suggested.
Class names are case-insensitive in PHP @sandervanhooft, only the Composer autoloaders (PSR-0, PSR-4) are.
Working on the OrderResource
statuses and status methods now.
Can someone with Order API domain knowledge check whether this test (link) is ok? If so I can continue with implementation.
(The docs are not ready for this yet, only stating "See Order status changes for details on the ordersโ statuses.", but no link is provided / page is not available yet.)
Class names are case-insensitive in PHP @sandervanhooft, only the Composer autoloaders (PSR-0, PSR-4) are.
Good to know ๐
Hi Sander, the status fields are as described in the docs. So your status methods are correct.
What we ment with the "order status changes details" is the transitions between statuses. We will add a guide for this and update accordingly.
Take a look at the cancel order endpoint docs and you will understand why we want such a guide ;)
Ok @Smitsel ! So I'm going to assume there's no additional logic to implement than (pseudo):
public function isSomeStatus()
{
return $this->status === ORDER_STATUS::SOME_STATUS;
}
Take a look at the cancel order endpoint docs and you will understand why we want such a guide ;)
Indeed I do ๐
Seems to me that there should be a isCancelable
method on the OrderLine
resource as well.
Perhaps this would require an additional isCancelable
field in the Order API response?
I noticed it on some other resources.
Ok, I'm mixing things up here. I think we need this isCancelable
method both on the Order and the OrderLine.
I can probably implement the logic client side, but I think it's better to include a isCancelable
field on both the Order and the OrderLine responses, to keep the logic where it belongs - server side.
Update: I've implemented Order.isCancelable() and OrderLine.isCancelable() with client side logic for now.
Like with the payment response, it has a isCancelable
field.
@Smitsel Minor doc issue: the id is missing on the Order line details. (Link)
As you can see here: nearly done with the implementation!
I'd like to manually test this against the private beta api when it's available.
@ndijkstra @Smitsel @willemstuursma
Next steps:
I just read up on the Order
docs. It seems the void
status is dropped, and the expired
status is new.
Is that correct?
@sandervanhooft yes we are indeed re-considering some of the statuses
@willemstuursma Thanks. So it's not final yet? In that case I'll leave it alone for now.
Added the examples.
@ndijkstra @Smitsel @willemstuursma
Similar to the isCancelable
field, I think there should be an isRefundable
field on the Order
response. What do you think?
We'll create a field for the refundable amount probably.
@willemstuursma Then an isRefundable()
helper would be nice
Order.lines
can be accessed as OrderLine
resources via the Order.lines()
method.
Can we do the same with Refund.lines
/ Refund.lines()
? Or is this is a slightly different resource than the OrderLine
?
Update: Just talked with @ndijkstra. He's on this.
@Smitsel When you review this, be sure to keep an eye out for OAuth compatibility. I've not explicitly tested this.
@sandervanhooft we want to merge this into a branch and create a pre-release, is that OK for you?
@willemstuursma Great idea!
I've just made some comments at the @Smitsel 's PR review #252 . And incorporated some of his remarks, minor new PR coming your way.
And received some feedback from @Smitsel already (thanks!). Will implement this, expect the PR later today.
I think we've got everything. If we still miss some stuff we can open a new issue :)
Specifications
Describe the issue
I am preparing the Order and Shipment integrations in this fork/branch.
Any discussion on the development can take place here in this issue.
PR is here: #252.
Endpoints:
OrderEndpoint
for/orders/*
:create
get
list
cancel
OrderLineEndpoint
for/orders/*/lines/*
cancelFor($orderId)
OrderRefundEndpoint
for/orders/*/refunds/*
create
list
ShipmentEndpoint
fororders/*/shipments/*
createFor
getFor
listFor
Resources:
Order
isStatusX()
lines()
shipments()
getShipment()
createShipment()
ship()
isCancelable()
cancelLine()
refunds()
refund(...)
OrderCollection
OrderLine
isStatusX()
isTypeX()
cancel()
isCancelable()
OrderLineCollection
Shipment
lines()
order()
ShipmentCollection
Types:
OrderStatus
:created
paid
authorized
canceled
refunded
shipping
completed
void
(dropped)expired
OrderLineStatus
:created
authorized
paid
canceled
refunded
shipped
void
OrderLineType
:physical
discount
digital
shipping_fee
store_credit
gift_card
surcharge
Documentation:
Order
26-new-order
27-handle-order-status-change
28-cancel-order
29-list-orders
30-cancel-order-line
Shipment
31-ship-order-completely
32-ship-order-partially
33-get-order-shipment
34-list-order-shipments
Order
create
get
cancel
list
cancel line
create refund
list refunds
Shipment
create
get
list