As a follow up to #33 I'm also removing empty usage on decompiling the Problem object to remove the following bug

<?php

echo ApiProblem::fromJson('{"type":"0"}')->asJson();
// expected {"type":"0"} but got {"type":"about:blank"} instead

The acme protocol returns in https://tools.ietf.org/html/draft-ietf-acme-acme-17#section-7.1.3 an error object which is in the format of RFC 7807. To get this informations into a ApiProblem we need to perform a json_decode of the payload. Extract 'error' and json_encode the data to be passed to ApiProblem::fromJson.

It would be easier to just have a static function like decompile named ApiProblem::fromArray() to perform the work.

@Crell This PR tentatively tries to introduce an Interface for the ApiProblem package.

I say tentatively because I wonder if this should be done using something la PHP-FIG or if this is useful to enable swapping or using other package using object following RFC7807 like https://github.com/phpro/api-problem .

Also I tried to extract the interface without introducing any BC break

If you find this useful the remaining/open question are:

Naming issues:

• should the interface be simply called Problem vs ApiProblemInterface
• should we used Problem::toArray vs Problem::asArray

New methods/classes

• the set/getExtensions methods are added to enable access to the extension members easily
• should we introduce a specific Exception if a setter method fails ?

Out of scope features

• Currently the Problem interface does not support the JsonSerializable or the ArrayAccess interface as such any conversion feature like asXml or asJson are not present in the interface and are specific to the current implementation.
• In contrary asArray is kept in the interface as the other representations can be infer from it. As a consequence, HttpConverter is rewritten internally to only work with the asArray method.
• Using PHP native JsonException as this requires at least a PHP requirement bump and maybe a full BC break.

let me know what you think

Crell\ApiProblem\ApiProblem sets $title (and $type) property only if argument isn't empty, but getters requires a string return value.

I think is possible to remove conditions in constructor. If you enable strict types, currently it would throw an error.

Same thing for other properties, they are null by default, but getters' return values aren't nullable.

When invalid JSON is passed to ApiProblem::fromJson(), I get a PHP notice and an exception:

• Argument 1 passed to Crell\ApiProblem\ApiProblem::decompile() must be an array, null given
• The provided problem string is invalid. The "title" property is required.

I think it would be appropriate to throw an exception about the invalid JSON, rather than one about the missing title.

Syntactic sugar I know, but there are many instances where objects are put through jason_encode() to serialise them. Once example is Laravel or Lumen, where you can return an object and it will be encoded as a JSON payload, for example:

return response()->json($problem);

It would be great if that were simply handled without converting to JSON first. The above example returns the payload as [] instead of an RFC7807 object.

These work for Laravel at present as the return from a controller:

return response($problem->asJson(), $statusCode, ['Content-Type' => 'application/problem+json']);

return response()->json($problem->asArray(), $statusCode);

I will look at the PSR-7 generation too, as that makes sense for other frameworks and simple apps.

Is this something that you prefer not to support, or just something nobody has got around to?

Simple JsonSerializable support.

This is useful in frameworks such as Laravel or Lumen that will accept any object as a HTTP response payload that can be JSON serialised.

Resolves #26

This adds a converter utility to convert a Problem object directly to a PSR-7 Response object.

At the moment it depends on Zend Diactoros for the Stream object support.

Awesome project.

It would be great to add an ApiProblem::asArray() method to get the compiled data as a native PHP array. The use case I have is to more easily integrate this project into a Silex app, where JSON data is returned by adding the following statement to your callback:

$app->error(function (\Exception $e, $code) use ($app) {
  // ...
  return $app->json($data);
});

Without a method to get a native PHP array, I have to re-implement some header-setting in the json() method in order for things to be treated the same way as JSON in the rest of the application.

Thanks in advance for any attention you can give to this, Chris

When upgrading an app to PHP 8.1, while using version 3.5.1, we see the following issues:

Deprecated: Return type of Crell\ApiProblem\ApiProblem::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in [directory]/vendor/crell/api-problem/src/ApiProblem.php on line 599

Deprecated: Return type of & Crell\ApiProblem\ApiProblem::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in [directory]/vendor/crell/api-problem/src/ApiProblem.php on line 607

Deprecated: Return type of Crell\ApiProblem\ApiProblem::offsetSet($offset, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in [directory]/vendor/crell/api-problem/src/ApiProblem.php on line 615

Deprecated: Return type of Crell\ApiProblem\ApiProblem::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in [directory]vendor/crell/api-problem/src/ApiProblem.php on line 623

Deprecated: Return type of Crell\ApiProblem\ApiProblem::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in [directory]/vendor/crell/api-problem/src/ApiProblem.php on line 520

Since some of the signatures will now include the mixed argument & return type (like offsetGet($offset) -> offsetGet(mixed $offset): mixed), this will mean dropping PHP 7.*

Maybe a new major version could be created to accommodate this?

• This PR add more PHP versions tests to ApiProblem (testing against PHP>=7.1 and PHP8)
• Switch from Travis/Scrutinizer to Github actions
• Switch from Zend-Diactoros to Laminas-Diactoros