swagger-php VS Nyholm PSR-7

Native PHP attributes allowed OpenAPI markup to be much more compact than in DocBlocks. The resulting openapi.yaml is created with swagger-php and used to test the API.

First, swagger-php generates openapi.yaml based on code attributes, and then the spectator checks API responses to match openapi specification. The popular L5-Swagger is redundant in this case, as it is based on the same swagger-php with the addition of Swagger UI.

I do this except use https://github.com/zircote/swagger-php for writing the open api spec. I can enter the Spatie Data Object classes into the parameters, responses, and properties. Like op said though, it's a lot of comments and stuff to keep updated. Entirely using reflection (or reflection plus ability to manually specify certain extra things) like you're talking about sounds great.

wagger-php is a php swagger annotation and parsing library which generates interactive OpenAPI documentation for your RESTful API using doctrine annotations. - GitHub - zircote/swagger-php

The second one is L5 Swagger, a popular package bringing Swagger PHP and Swagger UI to Laravel. We actually don't need Swagger PHP here, as it uses Doctrine annotations to generate OpenAPI definitions and we're going to manually write our own instead. We do need Swagger UI, however, and the package conveniently adapts it to work with Laravel (the -W option is simply here to also update related dependencies, to avoid conflicts).

I need to create REST API documentation for a legacy Zend Framework 2 project. I tried to use zircote/swagger-php . It works with the new zf2 skeleton project but it fails when I use it in the legacy zf2 project. It adds Symfony/polyfill-php80 and it generates to issue. Anybody could help me on this issue. If you can suggest another package for API documentation also be a great help. Thanks.

It is possible that there is a library doing this already. I am not PHP coder so would like to avoid complex frameworks and stick with barebone solution doing only this Swagger/JSON stuff. For swagger, I decided to go with zircote/swagger-php. I would like my schema and model classes to have nice Swagger doc and at the same time I can use them to prepare objects to interact with the DB by loading/dumping from JSON.

I'm using this library to generate an open api 3 (swagger) yaml file. You add @OA markup to your doc blocks and then can have this generate a file or produce it on the fly. It's a bit sparse on documentation but is working really well with my MVC set up for a REST API I'm developing. https://github.com/zircote/swagger-php

I like the swagger way of generating schema's by annotating classes.. Swagger/OpenApi 3.0 uses a slightly modified subset of json schema, would that be of use to you?

As the documentation states, this package only performs the conversion, so we would need a PSR-7 and a PSR-17 implementation to convert the objects to and from PSR-7. We can use the library the documentation recommends, nyholm/psr7, but there are others.

The following example shows how to create configuration for the HTTP factories, using the nyholm/psr7 package:

Since the library is designed to be easily integrated with different frameworks, it relies on the usage of PSR-7 compliant HTTP messages. To fulfill this requirement, I'll be using the nyholm/psr7 package.

If you go strict PSR-7, as you see in nyholm/psr7, Tobias uses traits to add the functionality of the extended RequestInterface and MessageInterface:

The Symfony folks thought of this, however, and provided a bridge that converts HttpFoundation objects to PSR-7 ones. The bridge simply needs a PSR-7 and PSR-17 factory, for which they suggest to use Tobias Nyholm's PSR-7 implementation.

“In theory, theory and practice are the same. In practice, they are not.” (Dr. Albert Einstein). I believe same goes for packages, too. A good example is the [comparison](https://github.com/Nyholm/psr7) of some PSR-7 implementations.

The point is why would I pull in code in the first place that is not needed? If it is optional, then why is it not a separate package? Same with all of the bloated HTTP requests and response objects that frameworks and other libs usually use. I really like https://github.com/Nyholm/psr7 for that reason, it has a table in it's readme.md that is pretty much enough to know why I like it. If something specific is needed it can be decorated or extended on project level.