What is the best architecture in Laravel for handling features that rely on external APIs (some with authentication, some without)?

Hello, I'll try to answer your questions.

1. Only if you think that it can be useful and reusable in other projects.

2. Could be a good idea ... but why with an external package ? you can do that without any package.

3. Seems to be like a similar approach as 2.

4. Seems to be like a similar approach as 1.

Yes Laravel is still a good choice for building a full API application. But I'm not sure what you are trying to do ... if an application is a full API one, that means that you don't have any frontend and only provide services (via the API) to developers.

If your application is a full API one, then yes you need to use a frontend like React, VueJS, ... And you have 2 choices : develop the frontend inside the Laravel project or develop the frontend as a separate application.

@alireza_hadizadeh If I were to build this, I’d extrapolate “functionality” from the actual provider, and then create something driver-based.

Think about Laravel’s mail component: regardless of which driver you’re using (SMTP, Mailgun, SES, etc), your code shouldn’t change and you just use the same methods (e.g. Mail::to($someone)->send(new FooMailable())). I’d do the same for SMS.

You can then also use interfaces to declare what functionality a particular SMS vendor provides. So I’d have interfaces for things that some vendors may offer and others may not; interfaces like GeneratesReports, ChecksBalance, SupportsTemplating, and so on. If the initial vendor you’re working with supports all of these then that’s great; you just implement all of the interfaces. But you may find you want to swap, and support additional, vendors in the future, and alternative vendors may not support all of these features. So you can implement only the interfaces corresponding to the functionality that particular vendor does support.

This should mean you don’t have to change any implementation code in your admin panel, as your admin panel should just be using some sort of wrapping manager class or façade to call methods (Sms::getReport(), Sms::getBalance(), etc), but that manager/facade calls the correct implementation based on configuration the same way Laravel’s components for cache, mail, queue, session, etc. do.

Is Laravel still a good choice for building the dashboard for such features

Back end part yes.

But it helps if you explain exactly what the API is for. There are hundreds of ways people do API's.

Also do you even need an API. I have seen so many questions on API's where a regular web app that's mobile friendly would be better suited.

Most API's, not including a mobile app, you aren't even concerned with a front end, the user of the returned JSON handles that.

They could be using:

• PHP
• Another PHP framework
• A java technology such as Spring Framework
• .Net Core
• etc

All of this has to be considered.

You main job is working out the instructions to use your API.

But normally if you aren't having a mobile app, then a regular web app works.

An example of an API would be a doctors office getting lab results from a lab. In such a case a developer would have written the code to deal with the JSON data for display.

But it sounds like you are using other API's, in such a case, what to use is subjective. I use either Fetch JS or Axios JS. But I suggest some tutorials on using an API and the different methods, like Curl and the many others. There are many ways (technologies) to in turn display the data.