-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
[HttpFoundation] Add ProblemDetailsJsonResponse
for HTTP APIs
#61208
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: 7.4
Are you sure you want to change the base?
[HttpFoundation] Add ProblemDetailsJsonResponse
for HTTP APIs
#61208
Conversation
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
2bbb577
to
7cecc40
Compare
src/Symfony/Component/HttpFoundation/ProblemDetailJsonResponse.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/ProblemDetailJsonResponse.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/ProblemDetailJsonResponse.php
Outdated
Show resolved
Hide resolved
Thank you very much @smnandre |
src/Symfony/Component/HttpFoundation/Exception/ProblemDetailJsonResponseException.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/ProblemDetailJsonResponse.php
Outdated
Show resolved
Hide resolved
Thank you @OskarStark |
Problem Details for HTTP APIs
ProblemDetailJsonResponse
for HTTP APIs
ProblemDetailJsonResponse
for HTTP APIsProblemDetailsJsonResponse
for HTTP APIs
src/Symfony/Component/HttpFoundation/ProblemDetailJsonResponse.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/Exception/ProblemDetailJsonResponseException.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/ProblemDetailJsonResponse.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/Tests/ProblemDetailJsonResponseTest.php
Outdated
Show resolved
Hide resolved
8befed4
to
a51dabd
Compare
The RFC also supports “errors”. Would it make sense to also support these in the class? |
Great. I missed that one because I was only scanning for „error“. |
src/Symfony/Component/HttpFoundation/Exception/ProblemDetailsJsonResponseException.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/ProblemDetailsJsonResponse.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/Tests/ProblemDetailsJsonResponseTest.php
Outdated
Show resolved
Hide resolved
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 feel like everything should be in the constructor, or, if we split in methods, computed lazily (but not sure that'd be useful here)
src/Symfony/Component/HttpFoundation/Tests/ProblemDetailsJsonResponseTest.php
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/ProblemDetailsJsonResponse.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/HttpFoundation/ProblemDetailsJsonResponse.php
Outdated
Show resolved
Hide resolved
49d5149
to
03299c5
Compare
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.
sorry I may miss a lot, so here are quick questions to help me understand
class ProblemDetailsJsonResponse extends Response | ||
{ | ||
public function __construct( | ||
private ?int $status = null, |
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.
what about making this not nullable and default to 500?
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.
Ohh thank you @nicolas-grekas.
I seriously have to do this.
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.
But the RFC does not specify a default status code. I just think it'll be wise to have a default and I don't know if 500 is okay.
if ($this->title && null === $this->type) { | ||
$this->title = Response::$statusTexts[$this->status]; |
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.
it looks strange to me to override the title if it's already set before
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.
If the problem type is not specified, the status code text is used as the title
When "about:blank" is used, the title SHOULD be the same as the recommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on), although it MAY be localized to suit client preferences (expressed with the Accept-Language request header)
$this->title = Response::$statusTexts[$this->status]; | ||
} | ||
|
||
if (null === $this->title && null === $this->detail) { |
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.
why the check about details?
|
||
$problemDetails = [ | ||
'type' => $this->type ?? 'about:blank', | ||
'title' => $this->title ?? Response::$statusTexts[$this->statusCode] ?? 'Unknown Error', |
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.
why didn't we do $this->title ??= Response::$statusTexts[$this->statusCode] ?? 'Unknown Error'
earlier?
private readonly ?string $type = null, | ||
private readonly ?string $detail = null, | ||
private readonly ?string $instance = null, | ||
private readonly ?array $extensions = [], |
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.
why do we need to have all these properties if we never access them after the constructor?
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.
@nicolas-grekas any recommended way to handle them? We are using these properties in the constructor.
Is the problem their visibility?
Thank you for the guidance.
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.
If they're not used after construct then they can be regular parameters
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.
Thank you @chalasr
This feature adds more detail to the HTTP response errors as specified by RFC 7807 and completed by RFC 9457
….php Co-authored-by: Simon André <smn.andre@gmail.com>
….php Co-authored-by: Simon André <smn.andre@gmail.com>
…onResponseException.php Co-authored-by: Oskar Stark <oskarstark@googlemail.com>
….php Co-authored-by: Oskar Stark <oskarstark@googlemail.com>
Co-authored-by: Oskar Stark <oskarstark@googlemail.com>
4c366c3
to
3f25fa6
Compare
This PR introduces the
ProblemDetailJsonResponse
which is an implementation of RFC 9457 to describe the specifics of a problem encountered: