thomasaull

Congrats for this update @Sebi I like the direction in which you push this module forward ?️

Doesnt the API Endpoint needs to be `testeapi/api` in this case?

Thanks for the quick fix @Sebi! Are you planning on using the new url hooks in the future? I read about it yesterday and it feels like a much cleaner way to handle the requests to the API endpoint

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?

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.

@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 I see… I guess you'll have to wait for an answer from @Sebi for this one That's right actually, I just checked the source, apparently there is no way to access the API without an API Key. The `auth` option only says, if a guest is allowed to access the endpoint. What's holding you back to use an API Key? I think the way to do it is to generate a new API Key for the new version. As soon as the client for the new version is released you can delete the old version. The clients which are still on the old version will get an Error like "API Key not valid" or similar which you can use in your client to guide the user to do whatever you want from there ?

@benbyf I'm going to try to give you some answers: What do you mean by „the log wasn't created for this module"? Can you clarify your question a bit? You can disable auth for certain routes by setting `"auth" => false` in the route options. This is not explicitly documented at the moment, but here is an example where it's set to true: https://github.com/Sebiworld/AppApi#example-listing-users Version numbers are a way to make breaking changes to your API and check for that in the client (e.g. if the client requests API v1 but the newer v2 should be used you can return a warning which the client displays to the user (e.g. to update the software, refresh the website, …) API Keys are way to guard your API to only be accessed by your apps. This is not possible in the browser, since the code would be readable but certainly for complied Apps If you want to restrict API access of certain user roles (`superadmin` is allowed more than `editor`) you'll have to add this logic by yourself in the route methods (it's basically ProcessWire API from there)

I got it working by using the ProcessWire Namespace in my php files: <?php namespace ProcessWire; echo 'break here'; echo 'this is after the breakpoint; I believe this way the files don't get compiled to the cache directory, which apparently causes the breakpoints to get lost

Hey everyone, there is a new module AppApi available which is based on my original RestApi module but has some additional features which are really cool! I have been struggling to find time for the RestApi module over the course of the last 1+ year, so I'm really glad @Sebi is stepping in and doing work in this area. I think it would be a good idea, to see AppApi as a successor of the RestApi module and put all focus and development efforts there. What do you guys think?

@Sebi I created issues for my requests except the API Keys question (I thought this might have been a low hanging fruit, but it looks like it's a bit more complicated)

Two more things: Can you enable Issues in your respository on github? I'm getting an error in this line: https://github.com/Sebiworld/AppApi/blob/master/classes/Router.php#L275 Changing it to if ($last_error && $last_error['type'] === E_ERROR) { fixes it. (This was already suggested by someone some time ago on the RestApi module). I was providing a PR, but since AppApi is a fork of RestApi, when I try to fork it, it just goes back to my module ?

Another thing which would make usage of this module easier for users of the RestApi module would be to have an option to not have to use ApiKeys to access the API

I already have the first request: I was planning to, instead using a hook to intercept the request to play out the api it would be better to (again) use a page in the regular ProcessWire tree for the following reasons: Multi Language does not work with the current solution Caching with ProCache does not work with the current solution It is harder for users of the API module to use Subdirectories Also another request by a user was to move the API routes in `/templates` so it would be included in exports with the site profile export module.

Yeah this is pretty awesome! Since I'm struggeling with carving out time for the RestApi module over the last year (sorry again for not giving your PR much love @Sebi) I'm pretty happy someone is pushing things forward :) Actually I'm thinking maybe this module should be the official continuation of my RestApi Module. For me it looks like it is more advanced and as far as I can tell by creating a single endpoint the way things are used would be quite similar. What do you think? I'm gonna check it out myself now :)