We have a requirement not to allow any address with "PO Box".If a user enters "PO Box" in the address field, we need to display an error message. How can this be accomplished in Hotcakes checkout process? Do we need to use integration pipeline or some Jquery?
The answer is that you could do one or the other, or both. If you do both, it would be a better user experience with instant feedback, combined with server-side validation. It's really up to you. Regardless, I'd highly suggest using the action delegate integration pipeline as a server-side catch-all.
Related
For example, if I’ve built a full conversational flow in a service like API. AI that results in a booking being made. How do I actually then make that booking sync to a third party calendar?
Can this be done directly between the two? Would I need to build an application to sit between the two?
I’m tech inexperienced, so I’m curious how these things work…
You will need to add "fulfillment" to your API.AI app, and yes, have a custom application (the "webhook") in between.
That is, once you've collected all the information to make that booking, you don't want to just say "Thank you, here's the book information you've provided [...]", you want to do things with it. That's what fulfillment does. API.AI will send a REST call to your webhook with the information the intent has, you do whatever you want with it (e.g.: actually add the booking to the calendar), and also return the response that you want API.AI to give, that'll take the place of the "text response" you normally provide for a given intent.
To set this up on the API.AI side, there are two steps: Find "fulfillment" in the menu for your app, and tell it how to connect to your webhook. Then go to any intent where you want the webhook to be called when it's matched, and select "use webhook" under "fulfillment".
The more involved part may be to actually provide a webhook that API.AI can call - that's where your custom logic goes, it sits between, in your example, the API.AI app and the calendar application and makes things actually happen.
Useful reading: https://docs.api.ai/docs/webhook
I have been reviewing this forum and the documentation for PayPal API but am still uncertain about one thing: Can I have an algorithm determine the price of certain services on a PayPal button (rather than designing a bunch of preset buttons and choosing which one to display)? I would like to have this information feed in from an external database and would appreciate any tips on which lever to pull.
Thank you!
You would have to make sure it's not a hosted button, which would make the amount be included in a hidden field with the form button. Then you could dynamically adjust the amount based on any logic you want.
The down-side to that is the button isn't as secure because people could view source, copy the HTML, change the amount, and then submit the payment that way. Of course, there are ways to manage this, but it's something to consider.
Another option would be to use the Express Checkout API instead, in which case it would be completely secure and fully customizable to handle pricing however you need to.
I am developing a RESTful API. This is my first API, but also my first really big coding project. As such, I'm still learning a lot about architecture etc.
Currently, I have my api setup in the following layers:
HTTP Layer
Resource Layer
Domain Model / Business Logic Layer
Data Access / Repository Layer
Persistent Storage / DB Layer
The issue I have run into at the moment is where do I need to put workflow objects / managers? By workflows, I mean code that evaluates what next step is required by the end user. For example, an e-commerce workflow. User adds item to basket, then checks out, then fills in personal details, then pays. The workflow would be responsible for deciding what steps are next, but also what steps are NOT allowed. For example, a user couldn't cause errors in the API by trying to pay before they have entered personal details (maybe they recall the URI for payments and try to skip a step). The workflow would check to see that all previous steps had been completed, if not, would not allow payment.
Currently, my workflow logic is in the Resource Layer. I am using hypermedia links to present the workflow to the user e.g. providing a 'next step' link. The problem I have with this is that the resource layer is a top level layer, and more aligned with presentation. I feel it needs to know too much about the underlying domain model to effectively evaluate a workflow i.e. it would need to know it has to check the personal_details entity before allowing payment.
This now leads me to thinking that workflows belong in the domain model. This does make a lot more sense, as really workflows are part of the business logic and I think are therefore best placed in the domain layer. After all, replace the Resource Layer with something else, and you would still need the underlying workflows.
But now the problem is that workflows required knowledge of several domain objects to complete their logic. It now feels right that it maybe goes in its own layer? Between Resource and Domain Layer?
HTTP Layer
Resource Layer
Workflow Layer
Domain Model / Business Logic Layer
Data Access / Repository Layer
Persistent Storage / DB Layer
Im just wondering if anyone had any other views or thoughts around this? As I said, I have no past application experience to know where workflows should be placed. Im really just learning this for the first time so want to make sure I'm going about it the right way.
Links to articles or blogs that cover this would be greatly appreciated. Love reading up on different implementations.
EDIT
To clarify, I release that HATEOAS allows the client to navigate through the 'workflow', but there must be something in my API that knows what links to show i.e. it is really defining the workflow that is allowed. It presents workflow related links in the resource, but additionally it validates requests are in sync with the workflow. Whilst I agree that a client will probably only follow the links provided in the resource, the danger (and beauty) of rest, is that its URI driven, so there is nothing stopping a mischievous client trying to 'skip' steps in the workflow by making an educated guess at the URI. The API needs to spot this and return a 302 response.
The answer to this question has taken me a fair bit of research, but basically the 'workflow' part has nothing to do with REST at all and more to do with the application layer.
My system was had the application logic and REST API too tightly coupled. I solved my problem by refactoring to reduce the coupling and now the workflow lives within the context of the application
REST encourages you to create a vocabulary of nouns (users, products, shopping carts) against an established set of verbs (GET, POST, PUT, DELETE). If you stick to this rule, then in your example the workflow really is defined by the set of interactions the user has with your site. It is how the user uses your app, which is really defined by the UI. Your REST services should react appropriately to invalid state requests, such as attempting to checkout with an empty cart, but the UI may also prevent such requests using script, which is an optional characteristic of REST.
For example, the UI which displays a product to the user might also display a link which would permit the user to add that product to their cart (POST shoppingcart/{productId}). The server really shouldn't care how the user got to that POST, only that it should add that product to the user's cart and return an updated representation of the cart to the user. The UI can then use javascript to determine whether or not to display a link to checkout only if the shopping cart has one or more items.
So it seems that your workflow lives outside the REST service and is rather defined by the navigation in your pages, which interact with your REST services as the user requests things. It's certainly possible that you might have internal workflows which must occur within your application based on the states setup by the user. But what you seem to be describing is a user interaction within the site, and while that's indeed a workflow, it seems better defined by your UI(s) than by a dedicated server-side component/layer.
You touch on the workflow (aka business logic) part of an API. Technically this is a separate concern from the API part which is the interface. Sure, as you mention, HATEOAS allows you to suggest certain actions which are valid, but you should be careful to maintain statelessness.
In REST applications, there must not be session state stored on the server side. Instead, it must be handled entirely by the client.
So, if there's session state on the server, it's not REST.
For your shopping cart example, you can save state in a separate caching layer like Redis. As for your workflows. You wouldn't want to put business logic like calculating their shopping cart or total bill in a domain model. That would be added to service layer.
You talked about mischievous users guessing URLs. This is always a concern and should be handled by your security. If the URL to delete a user is DELETE /user/3782 ... they can easily guess how to delete all the users. But you shouldn't rely only on obfuscating the URLs. You should have real security and access checks inside your endpoints checking if each request is valid.
This is the same solution for your shopping cart concerns You'll need to grant a token which will attach their shopping information and use that to validate each action, regardless if they knew the right URL or not. There are no shortcuts when it comes to security.
You may want to re-orient your architecture along the lines of DDD (Domain Driven Design) and perhaps use a MSA, that way you can shift from orchestrated workflow to EDA and choreography of micro processes.
My school is using a website to manage grades, homework and communication with teachers. Because there is no way to get automatic notification, most students have to use it daily to check manually if there's an update (new message, new grade, etc). Since their service has no API, what should I do to get automatic notifications.
Is there any tools available that automatically notify you (by email or rss feed) of any change in a page by authentifying and checking if the value of a specific field changed?
Should I code my own script?
Is there any tool or library out there that could make this task easier?
Thanks in advance for your answers.
https://www.changedetection.com/
Not sure if it works for secure websites, though.
I just found something interesting. It's called Scrapy. It's an application framework that makes data-mining and structured data extraction easier.
Has anyone experience with Scrapy? Could it solve my problem?
Is the backend used by reCaptcha open source? Is it a simple web app that can be deployed in a given container?
Thanks,
LES
It's a web service. It is supplied by a third party.
You can integrate it into your application, but as far as the source code goes, no. Its value is not in the source code but in the images that are supplied. They're not randomly generated but come from books from those parts an OCR system failed to process. So by solving reCaptcha people are actually helping scan books. Somebody takes care of the scanning process and supplied a constant flow of new challenges. Hard to beat.
Running reCaptcha on your own server would be very cumbersome, as it requires a constant supply of image data (scanned books) to work. Also it would kind of beat a part of the purpose, that is digitizing books for the common good. Besides, I don't think it's even available.
This should be able to answer all of your questions for you: recaptcha