DF can be a used to have a external API or is more for a backend API?

Miscellaneous
,
1

Hello all,

After a day reading the Wiki and Docs, and viewing videos, want to confirm if DF can be used to have a public API? I think to expose the API “outside” the DF interface is complicated!

The intention is to have a API to company needs (a backend API) to develop our services and websites. This API is only accessed by “company users”.
But need expose some API endpoints to general public to use by 3rd party developers (through a Key by each developer), the “API Docs” must be in a separated location from DF base (can be a sub-folder or a sub-domain).

It’s is possible? or the main propose of DF is to have a backend API to build websites/services, but not intended to be a public available (like Parse.com).

Best regards,
LB

2

Hello @LBat

With DF you can provide specific endpoints for Public and Authenticated users. The way to do this is by assigning a API Key + Role

For authenticated users, this article describes how you should do this https://blog.dreamfactory.com/share-api-docs-securely

In case of public users, you must at least identify a API Key, because it will be through it that the Role with the public permissions will be defined. This doc briefly describes how to configure it. https://wiki.dreamfactory.com/DreamFactory/Tutorials/Setting_up_application_default_role

Best regards

3

@LBat,

There’s not a way within dreamfactory to avoid having an API key; however I believe it would be possible to set do this with mod-rewrite in the apache server. I haven’t done it yet though so I don’t have instructions. Of course, requiring an API key has a lot of benefits around security and preventing DoS attacks, and isn’t a big burden on developers.

You could probably do the same using a proxy server, which would allow you to do some other checks on the request prior to passing it to dreamfactory.

1 Like
4

Hello,

Thank you @juniorconte and @jraiche.

Junior, the first part, “for authenticated users”, I put to work.

My intention is to permit a 3rd party developer use a API endpoint without need to make a login, the ideia is this “3rd party” developer in the call pass another key, something like a “X-Developer-Key” (can be with the Dreamfactory Key).

In the “pre-process” validate the “X-Developer-Key” and if all ok, the permit the request.

Now, It is made in the “Service” or need to create an “Apps” ?
To create an “App” is to create a folder in the server and create my code and configure “App” to use this url ?

I have “confusion” between a Service and an Apps. I think an “Apps” is not a API endpoint, but a ‘place’ to show (frontend) to a user (a clone of Swagger, or a FAQ page, Or a “Backend” to users…) !

Regards,
Luis

5

I was a bit confused by the Role vs App vs Service thing as well initially. If my understanding is flawed, I’ll defer to more experienced users.

Service: A Rest endpoint serving as the gateway to a service (code or database) that is exposed to the world. Services don’t know about security, only what methods/data they expose.

App: A way of controlling permissions across multiple services so a single application can consume aspects of many APIs. An application is a “way of using the api” - could be any interface or usecase. An app could access a part of one API or many APIs. I believe apps can also be used for tracking/auditing usage and controlling rates in some editions.

Role: A way of controlling levels of service within an app. Each app can have a default role, and each user (or group of users) can be assigned another role in the app.

For a concrete example, think about an enterprise application for managing invoices.

First, you have Services, here are 3 plausible ones for this application:

  • Handle scanned invoice I/O (an FTP service that also writes to a DB. Stores and retrieves invoices)
  • Make payment for an invoice (a custom script to make payments)
  • Report on invoices (a db service)

Now, the enterprise would have many more services than that. HR has their services, Legal has services, etc.

The App limits access to the three services above. This is done by providing the developers of the app with the API key.

Now, Audit doesn’t need to make payments, but they need to be able to look at invoices and report on them. The Audit Role is granted permissions to those tables, so when they use the Invoice App, they will be able to do a certain set of actions. If they use another app, they would be able to do audit-ish things in that app too.

Scanners have another role - they can only post to scanned invoice service, not read from it. This can also be controlled with a role.

I hope that makes sense!

Josiah

1 Like
6

Oh, and the default role feature of apps makes it so that they can just use the API key without logging in. You could even set the default role very permissive during development and lock it down once the app is in production so that users would have to login.

1 Like
7

Hello again @jraiche,

It is a good explanation, I try to divide my structure in this three ‘areas’ and verify if works.

I will return when have more conclusions or have more questions.

Best regards,
LB