I want to create an API in the Strapi. When this API hits, it will fetch data from another API service and store the strap as well. Later when I use this Strapi API I will use the previously retrieved data.
I found a documentation about external data, but the example here is hard to fully understand
https://docs.strapi.io/developer-docs/latest/guides/external-data.html
This is how you can do that in a Strapi.
Create a new model to store external API then add a new controller with those steps:
Check if requested data is present in database (using an unique ID or any way to identify the data for example)
If data exists, return it
If not, use 'axios' (installed with Strapi) or 'request' to fetch the external API
Store the fetched data
Return the fetched data
Related
I want to build a project where a user will be able to press on a button to authorize my platform to access their data (e.g shopify data). When my platform has access (to their shopify platform) it will send that data to my database.
My questions is:
In order for my rest api to access the data (from e.g shopify platform) i have to give the rest api the api key of the user which is simple if it a single account, but when i have multiple users using the same rest api how should i handle it? How can i give the rest api the access code so it can pull the data (from e.g their shopify platform) for each user? What is the name of the technology that needs to be considered here?
I am a built lost on the terminology of my question which has given me a bit of a headache when trying to google it.
First off, you create an App that Shopify approves, and then your merchant customers would install this App in their store. That approval process by both Shopify and the merchant means you are given permission to access their Shopify data.
Next, you create some value by allowing the merchant to see their data in ways unique to what it is you are doing. So far, your database contains nothing but the name of the store and the access token with permission to access the Shopify API.
How you then proceed in your own App is up to you. Not much else to it really, if you already know what your value add is. Code that part up and you're done!
If I'm wrinting BDD style tests. What would be better practise:
When User A creates new record
Then DB contain correct record
or
When User A creates new record
Then User A can get his new record by some API request
And Admin-user can get this new record by another API request
So should I check internal state of DB or just use API and consider application + DB as a black box?
You should test your application as much as possible using the APIs, as it gives the actual behaviour of your application. In your case, it would be
When User A creates new record
Then User A can get his new record by
some API request
And Admin-user can get this new record by another API
request
Reason being:
By using the Admin API, you are making sure the record is in database and the Admin API behaves as expected
In the future, if your DB changes, which is internal to your application, but the API's behaviour doesn't change then your BDD would work without any issues. In other words, if the devs decide to change DB and not the API, the business service which uses the API is not impacted
If you test only DB, but the Admin API changes, your scenario would pass but the Business service, which uses the Admin API, would fail
The only scenario, you would check the record in DB directly without an API is, when there is no API to verify the record. You shouldn't develop an API purely for BDD. The Admin API should be used in a business service and if this is not the case, you can check the DB record directly (your 1st option).
PS: We have developed a product NoCodeBDD. As the name implies, you can automate BDD without any code using NoCodeBDD. I would love to get some feedback from the community. You can download a free version from www.nocodebdd.com/download
Generally the thing that creates should be the thing that validates. So
if a user (human interacting with a UI) creates
then a user interacting with the UI would validate by viewing the created thing.
if an api client creates
then the api client would validate by examine the response from the create call
additionally the api client could get the thing created using a link in the response
In both cases I would only consider validating via the DB as a temporary measure whilst you are working on the scenario
I am using the embedded UI for template and document creation. I want to know the data which are being filled in the UI and also have to store them in my DB and then hit to 3rd party tools for signing. Is this flow possible to store the data in my DB?
With the HelloSign API, you have a few options to get information on the template:
The Get Template Endpoint
GET /template/[:template_id]
Gets general template details and includes a list of Accounts that can access it
https://app.hellosign.com/api/reference#get_template
The Get Template Files Endpoint
GET /template/files/[:template_id]
Obtains a copy of a template's original files.
https://app.hellosign.com/api/reference#get_template_files
And lastly, if you want the info that is being entered by the signer, you can poll the API or listen for callbacks that will supply you with said data to store in your DB.
https://app.hellosign.com/api/eventsAndCallbacksWalkthrough (best practice)
The Get Signature Request Endpoint can be used to poll this information
GET /signature_request/[:signature_request_id]
Gets a SignatureRequest that includes the current status for each signer.
https://app.hellosign.com/api/reference#get_signature_request
I am trying to use Azure Logic Apps to read data from one of the Salesforce objects which has huge number of records. The Salesforce connector fetches the record and returns the pagination link as #odata.nextLink. But when I try to use a JSON parser to read the value it’s coming as null.
I tried to access the nextlink in a browser but it requires authentication. What authentication do we pass here ?
I would like to use an until action to iterate till I get a next link . So how do I check the condition for the until loop ?
nextLink doesn't look like core Salesforce thing, it might be the OData connector preprocessing the results for you. You'd have to consult the documentation for the connector (if any).
Salesforce's REST API will return field with nextRecordsUrl if there's next page of results, you'd call that in loop until the field disappears. You'd call it like any other REST API resource available after login, by passing Authorization: Bearer <sessionId also known as accessToken here>. Again - probably the connector abstracts this away from you. Don't think you can send headers like that in browser, you'd need curl, Postman, SoapUI or similar http client.
If you don't get better answer and documentation is scarce - consider using raw REST API. Or Azure Data Factory has an almost-decent Salesforce connector?
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_query.htm
I've looked at various approaches to this but I'm yet to find one that is perfect for my set up.
I have a UI that calls the api to present data to a user - the UI doesn't require someone to login and i don't want to authenticate every user. What i'm trying to do is simply protect the api because with the url to the api, anyone will be able to access the data.
In my mind, i can create a password/ apikey of some sort and store that as an environment variable that is sent from the UI to the API whenever a request is made. On the API, that apikey/password is validated before allowing access to the api.
Does this sound wise? Would you suggest something else? Have i missed anything. All thoughts are welcome.
The solution sounds good to me. You can do something like this:
back-end: create a new REST endpoint (something like /api/get-token) in your Node.JS application which generates a token (or ID), saves it locally (maybe into a DBMS) and returns it as response. Then, in every endpoint you need to protect, you extract the token from the request and, before sending any "private" data, you check if the supplied token is valid, or not.
front-end: as soon as your application is loaded, you send a request to the newly created REST endpoint and store the given token locally (localStorage should be fine). Then, every time the UI needs to access "private" data, you simply supply the claim within the request.
The implementation should be pretty straight forward.