Fixed bug to retrieve PDF shipment label

[rickyheijnen]

Description

Something has changed in de DHL API which made retrieving shipment labels impossible.

Motivation and context

fixes #64

How has this been tested?

Current unit test were failing, so no new test were needed to test this.

1) Mvdnbrk\DhlParcel\Tests\Feature\Endpoints\LabelsTest::get_a_label_by_id
Mvdnbrk\DhlParcel\Exceptions\DhlParcelException: Unable to decode DHL Parcel response: '%PDF-1.4

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

Go over all the following points, and put an x in all the boxes that apply.

Please, please, please, don't send your pull request until all of the boxes are ticked.

• I have read the CONTRIBUTING document.
• My pull request addresses exactly one patch/feature.
• I have created a branch for this patch/feature.
• Each individual commit in the pull request is meaningful.
• I have added tests to cover my changes.
• All new and existing tests passed.
• If my change requires a change to the documentation, I have updated it accordingly.
• My code follows the code style of this project.

If you're unsure about any of these, don't hesitate to ask. We're here to help!

[rickyheijnen]

I'm a PHP developer for over 15 years now, and this is my first pull request on GitHub ever 🥳 this is so much fun!

[olia-bn]

Would it not make more sense to do !== application/json instead of == 'application/pdf' since the rest of the function explicitly handles JSON ?

[jacobdekeizer]

My application is also failing because of this issue. I Agree with @olia-bn, it's more future proof, e.g. if they revert it back to application/octet-stream.

[rickyheijnen]

Thanks for the comment. I first tried !== application/json, because that would indeed make more sense. But then some other test were failing, because sometimes the Content-Type is text/plain, but still containing JSON response.

I will look into this again to create a more future-proof solution.

[gamerlv]

I would like to add that this would also need to check, or at least handle, the mime-type application/zpl as that is another valid content-type accepted by the DHL api.

I've had contact with DHL about this change and they only realized that it was breaking a few libraries after it was already live. For now that are not reverting it as quite a few other libraries have already been updated to handle the change.

[rickyheijnen]

Based on your feedback, I've changed the way API call responses are handled. This should be future proof if DHL decides to change something again

[mvdnbrk]

Is application/zpl a valid mime type?

Can't we just simply check for the mime type application/octet-stream?
Or both application/octet-stream and application/pdf

[rickyheijnen]

According to the API documentation the /labels/{id} endpoint can response with application/json, application/pdf or
application/zpl . But the performApiCall method is used for all endpoints, so I think it is better to not check for one of these content types , but only check for application/json and then handle the request as a JSON response.

[mvdnbrk]

Well the return of a PDF is just an exception.
The easiest way to fix this for now is just by checking for application/pdf which is the correct mime type.

Release that as a fix release for now to keep everyone going.

If there are better solutions we can do that in another PR.

Thanks!