Yes: so that when somebody requests via the browser, they get markup. That said, most browsers have
*/* as the highest priority, and with the negotiation priority rules we’ve specified,
application/json will be selected in these cases.
Additionally, somebody pointed out that absence of an
Accept header implies
*/* per the specification, and so we now make that happen.
As such, there are very few cases where you will get XML; it should only happen at this point if you specifically accept only XML, or if you have it higher priority than JSON, both of which require some effort.
No. This needs to be turn-key, and not require the user to manually add more dependencies. Additionally, doing so adds to the logic substantially, as we then need to have different negotiation rules based on whether or not XML generation is possible.
That’s a good question; I need to look and see how the various distros are handling ext-json at this point. There was indeed a period where it wasn’t included by default, but I’m not sure that’s the case any longer.
No! The whole point of the Problem Details specification is that it is extensible, and allows you to provide additional data at the top level, so long as it does not conflict with any specified keys. If users what data pushed down a level, they can do so via nested structures provided the
This should be in a separate contributors topic, I think.
As I developed this library, I realized that most phpdoc was redundant: parameters and return values did not typically need documentation unless:
- The value could vary type.
- The value had additional constraints.
I added docblocks when either of those conditions occurred, but only to document the specific parameters and/or return values that needed documentation. I would also add docblocks when:
- I was throwing exceptions.
- I needed to explain the purpose of a method.
I have no idea how IDEs and/or phpdocumentor are currently handling the situation with PHP 7.1… which is why I think this needs to be part of another topic. Could you start that, please?
Why? (truly curious)
You indicate in some cases that we then have duplication in naming; that said, when I import these classes, it’s often nice to have something descriptive:
ResponseFactory can be quite ambiguous when you’re importing it!
You also indicate you’d prefer separating the exceptions to their own subnamespace — why? What does that specifically give us?
I’m asking these questions, because I found myself asking why I was separating classes into separate directories as I developed this component; it wasn’t gaining me much, but was making things like importing harder and more ambiguous.
I definitely think that as a component grows and specialized subtypes and subfunctions start appearing, segregating makes sense; I’m doing exactly that in the HAL module now. But I’m starting from a point of “if it’s related, why not keep it together?”
So, I’d love to hear your arguments!