0

I want to replace our in house REST system with Apigility and have some questions.

  1. We have large number of resources (about 1500) that are hierarchically structured. Apigility works with flat list of resource. This is ok when there are about 100 - 200 resources. At large numbers it may be quite difficult to handle. Is there any way to break structure into submodules or categories or similar?

  2. Since Apigility store all configuration in text files, large number of fields and documentation might cause problems with performance and/or with memory. Is there any way to split fields/configuration into separate files (or something)?

  3. Some resources are used for PDF file download. Is it possible to provide oAuth2 access token using GET method? Link to the file is created with A tag and that can not use HTTP headers.

Peter
  • 904
  • 1
  • 13
  • 26

1 Answers1

0

1. Yes, you can use several modules with their own module.config.php files like you would normally do inside a ZF2 application. It is also useful to split into several config files. You can for example create: metadata.config.php, controller.config.php and inputfilter.config.php

And then merge the config files in your module.php Module::getConfig method. This can help you get organized.

2 It is easy to overwrite/extend the default configuration of Apigility modules. Depending on how far you want to go with customization you can also built your own factories and mappers where you can try to minimize code duplication in your config files. When caching like normally in a ZF2 production environment your config files should not have that much impact on performance.

3. Yes, you can pass access token in the url using:

api/v1/documents/1?access_token=1234567890abcdefghijklmnopqrstuvqxyzABCD
Wilt
  • 41,477
  • 12
  • 152
  • 203