New Module: AppApi

[Sebi]

I'm here! ?

Hi @benbyf, I'm glad that your using AppApi! Let me clear this up a little:

1. It's a bug, I am linking to a protocol named 'app_api' in the module's settings, but the actual logs are written in a log named 'appapi-exception'. I will create an issue for that...

2. @thomasaull is exactly right. Currently there is no way to connect to the api without an api-key. It is necessary, because the key is needed to identify which application-configuration should be used. I am definitely planning to make it possible to define a "default"-application, that handles requests without an apikey, but it will need some time...an 

3. I would generally create new apikeys, even for small version-steps. If you need to block an old version, you can set the accessable-until field of the apikey or simply delete it.
What I don't fully understand is what you mean by "form_version", @benbyf. You can define an endpoint api/v1/test and api/test and let them handle requests from different versions. But the module does not automatically handle versions, add v1 to your path or something like that. Maybe you can specify what you are trying to achieve here?

Lastly, I must honestly state, that I am very busy with a very time-consuming project at work, which is why I do not find much time to work on module-updates. It will probably take until Christmas until i can put time into the project again. So if you understand the module's internal logic, I would be thankful for your pull-requests...

 

[benbyf]

Thanks both @Sebi and @thomasaull I appreciate your time.

Will look into the log bug as thats paramount to us using the module so would be great to clear up.

The non-apikey endpoints is more of a nice to have really as you can set up informational endpoints that act like website frontends but without the visual code obviously.

In terms of users, applications and version, they seem loosely connected. There seems little reason to fill out the apikey version  when creating a new apikey if it doesnt actually relate to anything. But maybe i just havent seen how it does or could relate. Also the users are too loosely associated with the applications (slight tangent), but it would be nice to leverage the user and roles system byt associating a user/s with either key or applications, and then auth them against them on route. e.g. [..., [route_options_role_required = "delete-pages, update-pages, create uses" ]] as the folowing api might enable these things and you wanna be pretty damn sure that user is allowed to do it ?

[thomasaull]

@benbyf I think that's not possible out of the box with the module. If you really want to use one api key per user you somehow would need to programmatically create them and store a reference on the user. But honestly this doesn't look like a good solution to me.

You're free to add any checks in your API functions to restrict certain user/roles from doing things, and that is probably how I would handle this. This way you can leverage the entire ProcessWire API. For example:

// Route: /api/publish-page/{id}

public static function publishPage($data) {
  $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['id|int']);
  $page = wire('pages')->get($data->id);

  if(!wire('user')->hasPermission('page-publish', $page)) {
    throw new Exception('Not-allowed'); // Or use AppApiException here
  }

  // Publish page   
}

 

[benbyf]

Hi @Sebi I added the log to app-api (will create a PR somepoint soon), I wondered if you wanted a log message on each request and maybe a setting in the modules settings to turn on or off, or maybe something more granular?

My use case is going to require lots of log messages in the api files but having a generic log message on each request I though might be nice. Also wondered if it was worth making a second log for failed (exception) based log messages? so successful requests get logged to one and exceptions to the other..... any thoughts would be cool

[David Lumm]

Hi @Sebi I'm pretty new to ProcessWire and I've started using your module to add an API. I'm really appreciating all the work from you and @thomasaull as it's making my life much easier!

I've spotted a couple of issues around HTTP statuses, one of them I've managed to do a PR for, it was pretty straightforward. The other issue is potentially a bit more complicated, or at least requires a bit of careful thought.

Currently you can't set the response code, it's just hard-coded to 200, but I'd like to send a 201 on create. I can think of at least two ways of doing it, one is quick but messy: return the status as part of the handler response; the other is probably neater but needs choices to be made: add a function (but where? AppApiHelper?) that stores the status and then retrieve it in the router.

Any thoughts?

[thomasaull]

Hey @David Lumm, thanks for your suggestions and PR with improvements. I haven't had the need yet, but it's definitely a function which should be included in the AppApi module for sure.

[Sebi]

Hi everyone!

I just wanted to give a quick sign of life. The time of Christmas vacation is finally reached and I can finally invest time in open source project again. Thanks a lot for your input. In the next days there will finally be an update for the AppApi module. I would then like to provide you with a development state for testing before a new master version is released.

Let us list the feature-requests:

• Error when importing database dump: Cannot add foreign key constraint (by @thomasaull)
• Multi Language and ProCache do not work 
• Weird HTTP status responses (by @David Lumm, thanks for PR ?)
• [Feature] Add multiple levels to routing config (by @David Lumm, thanks for PR ?)
• Optional extended logging like @benbyf said earlier. Created Issue #10 on Github so I don't forget it. 
• I will look into the other bugs and issues discussed here as well.

Did I leave something out? Thank you for your help and stay tuned for the next updates!

[3fingers]

... not a module request but I'd love to have a snippet of code to access and expose Repeater Matrix Fields inside the docs :) 

[Sebi]

Merry Christmas everyone! I hope you have some peaceful and calm days! ?

If you've been keeping an eye on the commits in the meantime, you'll have seen some progress for the upcoming version 1.1.0. The current status in the develop branch should be as good as finished in terms of programming. Only the readme has not yet been adapted. I want to move large parts of it to the repository wiki and then add more examples.

If you have some time, I would be very happy if you could test the new features (develop-branch).

What's new:

• Improved AppApi-dashboard
• Allow multiple levels to routing config (by @David Lumm, thanks for PR ?)
• Allow requests without an api-key: You can now mark an application as "default application". If you did so, every request without an apikey will be linked with that application.
• You can now set a custom response-code in case of success. Simply include your response-code number on key "responseCode" in your result-array. For example my test-function, which is called on a route in Routes.php:

<?php
class AppApiTest {
    public static function test($data) {
        return [
          'success' => true,
          'responseCode' => 202
        ];
    }
}

• Optional access-logging: You can enable access-logging in the module's configuration. After that, every successful request will be logged with it's application-id, apikey-id and token-id.
• Added hooks to all essential functions - that should enable you to customize the module's behavior even more. E.g. you could add custom logging on a hook, if you need that
• Database-scheme does not need foreign-key constraints any more. That should fix @thomasaull 's issue with db-backups. After the update, you must remove the constraint manually because I did not find a way to remove the foreign key safely in all database-environments.
• Multiple other bugfixes

What do you think? I look forward to your feedback!

[csaggo.com]

Great news @Sebi will test in the next couple of days!

[thomasaull]

On 12/20/2020 at 7:06 PM, 3fingers said:

... not a module request but I'd love to have a snippet of code to access and expose Repeater Matrix Fields inside the docs ?

What you do in your API functions is not different from what you would do in regular ProcessWire templates. Is there anything specific you need help with?

[Sebi]

On 12/20/2020 at 7:06 PM, 3fingers said:

... not a module request but I'd love to have a snippet of code to access and expose Repeater Matrix Fields inside the docs ?

@thomasaull is right. I have added an example in the Wiki, in which I demonstrate the output of a RepeaterMatrix-field "contents" that I use in most of my projects:

https://github.com/Sebiworld/AppApi/wiki/3.1:-Output-Formatting#complex-data

I hope, that helps. Generally speaking, you can output anything you want via api. You only have to transform complex structures like ProcessWire-Pages, Repeatermatrix-fields, ... into something that is JSON-encodable.

[3fingers]

Thanks @thomasaull and @Sebi (I've just bought you 3 coffees).

Keep up the good work! :)

[Sebi]

4 hours ago, 3fingers said:

@Sebi (I've just bought you 3 coffees)

Thank you @3fingers ! Your coffees will help me to stay motivated ☺️

[derixithy]

I just installed the module, but everytime i add an application i get an SQL error.

The application could not be saved: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: '' for column `planner`.`appapi_applications`.`default_application` at row 1

[Sebi]

Hey @derixithy, 

I've just set up a new ProcessWire-instance (current stable 3.0.165) and installed the module. Everything seems normal and I can add applications without getting an error. Maybe it is a problem with your individual configuration, can you give me additional details (e.g. ProcessWire-version, was AppApi installed before and updated to v1.1.0, or is it a fresh install? What PHP-version do you run?)

The following is the INSERT-statement I use to create a new application in db:

$createStatement = 'INSERT INTO `' . AppApi::tableApplications . '` 
(`id`, `created_user_id`, `created`,`modified_user_id`, `modified`, `title`, `description`, `default_application`, `token_secret`, `accesstoken_secret`, `authtype`, `expires_in`) 
VALUES 
(NULL, :created_user_id, :created, :modified_user_id, :modified, :title, :description, :default_application, :token_secret, :accesstoken_secret, :authtype, :expires_in);';

So let me try to interpret the error message... "Invalid datetime format: 1366" - 1366 looks like a user-id, that should be used as variable :created_user_id. But it tries to insert that value to a datetime-column, which could be the 'created'-column that follow right after that in the insert-statement. So it looks like that something went wrong with the variable-values for the PHP-prepared statement I use. 

You find the create-statement here in the code: https://github.com/Sebiworld/AppApi/blob/65911a3f13c6420ffad0e68b34d8c51a8b1eb99c/classes/Application.php#L614

Have any of you ever seen anything like this?

[David Lumm]

Great work @sebi!

Am I reasonably safe to upgrade to the 1.1.0 version, it won't break anything?

[Sebi]

Hey @David Lumm, thanks!

Short answer: Yes, I'm pretty sure that upgrading to 1.1.0 will not break anything.

Longer answer: Every previous functionality will work as before - there are only additional features, but no breaking changes. During the update the module will add a new column "default_application" to the appapi_applications table. Everything else stays the same.

To be on the safe side, I tested upgrading to 1.1.0 and new installing in multiple different configurations. Besides @derixithy 's comment above I did not hear any problems. But if against all expectations you notice something, feel free to contact me ?

[David Lumm]

Hi all. I think we have a serious problem. I'm just trying to prepare an API that I've developed for release and I can't create new applications. Something to do with the default application flag, I think: https://github.com/Sebiworld/AppApi/issues/16

@Sebi is there anything I can do to help get this fixed quickly?

[Sebi]

Hi @David Lumm, I'm workung on an emergency fix. Still cannot reproduce the problem, but I will try to change the datatype of the default_application-column from boolean to int. Hopefully that fixes it. 

[Sebi]

17 minutes ago, Sebi said:

Hi @David Lumm, I'm workung on an emergency fix. Still cannot reproduce the problem, but I will try to change the datatype of the default_application-column from boolean to int. Hopefully that fixes it. 

@David Lumm: v1.1.1 is out. It changes the datatype to int(1). Works for me - can you please check if that fixes the error on your configuration, too?

@derixithy: You mentioned the same error - I hope that v1.1.1 fixes it!

[David Lumm]

Thanks for your quick work on this @Sebi. That seems to have fixed it for us!

[thibaultvdb]

Hi

When using the module with version 1.1.1 I have a strange issue with using the "StdClass".
I keep getting the error as you can see in the screenshot "Cannot use object of type stdClass as array".

In previous projects similar code was working fine, something broken with this? My calls are just regular GET requests.
If I don't use the "stdclass" I'm not receiving errors anymore.

[Sebi]

Hi @thibaultvdb,

thank you for reporting this issue! 
I'll be honest: In my Apis I actually always use arrays as return values, so I didn't notice this bug. With version 1.1.2, which I just released, you can use a stdclass again instead of an array as return value. 

I hope everything is running smoothly again with your Api? I would be very happy about a short feedback!

[David Lumm]

Hey all!

I was wondering, is there any concept of "middleware" or hooks that I could attach to so I could run something on every request?

At the moment I've got a couple of things I've added into every route function, but I can anticipate that list getting longer. Rather than copy and paste the same lines into each and potentially miss something, it would be great if I could run it before the route specific code runs. Is that possible @Sebi?