I would know how I can create an Homey Flow Card with arguments populated dynamically.
Than you
It is not possible to change what arguments a Flow card has based on the values entered by the user. It is recommended to create multiple Flow cards with the combinations of arguments that you want to support. Users can then pick which Flow card they want to use.
An example would be a Flow card that creates a HTTP request. Instead of creating a card where the user enters the HTTP Method, you can create multiple Flow cards for GET, POST etc.
This way you can chose to only add an argument for the request body to the POST request card.
Hope this answers your question, if I misunderstood please let me know.
Related
I'v built an app that creates ads using the marketing API. When it creates the adset it sets a specific pixel and a page view event.
All our users get the correct pixel and the correct event except for one user.
Here is the object from the post request that is being sent to Facebook where we can see that they are equal
User one
"promoted_object":"{\"pixel_id\":xxxxxxxxxx63,\"custom_event_type\":\"CONTENT_VIEW\",\"pixel_rule\":\"{\\\"event\\\":{\\\"eq\\\":\\\"PageView\\\"}}\"
User two
"promoted_object":"{\"pixel_id\":xxxxxxxxxx63,\"custom_event_type\":\"CONTENT_VIEW\",\"pixel_rule\":\"{\\\"event\\\":{\\\"eq\\\":\\\"PageView\\\"}}\"
Both get the correct pixel with the correct id but one gets no conversion event, and say Missing conversion event.
Both ad accounts have full access to the pixel under the business settings in ads manager.
Here is an image that describes the issue.
Anyone have any ideas here?
make sure the conversion event is defined in that account.
The conversion event is usually set on Campaign Level and supplied when you create a campaign via API.
As you're trying to use a custom conversion it might be that you've created it for one account but didn't create it for another. That's why you don't see it in you campaign setup view. You can create it via API as described here:
Custom Conversion API
Or just do it via Business Manager and use it afterward when creating you campaigns via API or manually.
It's definitely not a request that fails in this case but a proper account configuration.
I've come from a background of ASP.Net MVC where when the user wants to create a new entity the server returns values to populate drop down lists(for example).
Now I'm doing a UI that is invoking a REST Api. I have my urls for creating/retrieving etc but this is purely for actual resources. How would the REST be defined to get data to populate the create form.
For example:
a user wants to create a new order. They go to the 'create order' screen and need to select their payment method. They have 3 payment methods (card, paypal, amazon) but the logic on the server side knows that amazon cannot be accepted on this order. How would I go about letting the UI know what can be populated in the drop down list using REST?
I can't seem to get this to fit into REST principles but then I don't want the user to submit amazon and then the server return a Bad Request, just seems bad implementation.
Thanks
We have simple e-commerce website where we have several products. Currently, each product has "Place order" button.
When user clicks on this button, we show user a form to fill Name, Mobile number and address. We don't support any monetary transaction. Once user fills this form, the order is saved to database. The order table has OrderId, ProductId, UserName, UserMobile.
We are designing API to save the user order. Should we have association b/w product and order while designing this?
For example URI to save the user order should be like:
POST /api/products/1/lead/ - The request body has user information i.e. name,mobile,address. OR
POST /api/lead/ - The request body has "PRODUCT ID" and user information i.e. name,mobile,address.
I am confused whether productId should be in request URI or in the request body? How do we make such decision?
Given that
you're first navigating to a product, before actually placing the order
the product id has nothing in common with the UserInformation model that you're posting
I'd go with the first option: POST /api/products/1/lead/
I would always go with a more shallow route for representing resources, just for the sake of simplicity. No, a nested route isn't complicated or anything, but I've seen nesting go really far. So I would keep it as shallow as possible unless...
1) You plan on having more than one thing that can have a lead. For example, you can have a lead on a product:
api/products/1/lead
or a lead on a managed service that you all provide or something (I'm reaching right now):
api/managed_services/2/lead
You could pass that info in the body always, but I imagine it would become a little cumbersome to base what resource to create based on what properties were defined in the json.
2) You plan on breaking out that route and having it go to a different service eventually. Maybe this app will have to scale substantially and a ton of users will be hitting this route moreso than any other endpoint in the system. It's a lot easier to redirect all requests to a different microservice based on the url starting with api/products than it would be redirect based on the request body.
But honestly, I don't think it matters too much. As long as it's easy for your clients to consume.
I'm designing a REST api that allow client side to POST (create) a resource.
Let's call my resource is Subscription and my REST api accepts a Dto called Subscription
The POST request needs to be sent together with a captcha token that will be verified on server side.
My question is where would be the best place to put the captcha token, there're some options that I'm thinking about:
Directly inside Subscription
As a parameter in URL, e.g: /subscriptions?captcha_token=abcd1234
As a HTTP header
Create a new Dto that wraps Subscription and carry field captchaToken
Any other suggestion are welcome.
Thank you.
For anything authentication or authorization related I typically rely on headers or querystring parameters.
Generally I don't like to commingle payload with auth-related material, nor do I like to encapsulate it.
Having it in an HTTP header or as a querystring parameter gives you a good amount of isolation there. Also since it's independent of the request body you can implement broader auth controls for every API call without being dependent on the presence of a request body (important for GET requests which shouldn't carry a request body anyway).
Using a HTTP Header is only an option if your clients can modify / send HTTP Header information. This approach does not work for Standard Browsers.
You are not filtering a resource, so a query parameter from the REST Point of view does not make sense, and you don't want to send the captcha answer as query parameter.
Usually the one submits the captcha information (id, answer) together with the form data (payload). You also usually display captchas together with the form.
So at the end the only useful option is to send the captcha information as part of the payload / form data.
If you should put the data into your Subscription DTO or not depends on your design / preferences.
I'd suggest to use something like a Subscription(Data) and SubscriptionRequest where the SubscriptionRequest contains the SubscriptionDataand the Captha Information (capcha id and answer)
I am a newbie who is writting ASP.Net web API service for the very first time. The issue I am having is how to pass user information or different contexts via service request. For example I want to pass user context (i.e username, user preferences etc.) and lets say security context (i.e. api key, secret etc.) thru each service call. The options I found
1. using Query string
2. custom HTTP headers
3. overload authorization header to pass Jason object
4. cookie
I ditch the idea of using query string as it has 2k limitation, custom header could be ripped by proxy services, dont want to use cookie,creating a jason object of all the context and send it via auth header can work but seems like not a smart way. Any idea? what is the best way of passing those extra information.
I really appreciate if someone help me with some examples.