Can Square work in a CF ecommerce site? From our developer: This will be a bit technical but the way their API system works is they encapsulate the credit card data directly from a form entry with their css and js files. That system generates a "nonce" that then gets processed through the actual API REST call. That works fine in many typical sites. But we would need to make that REST call without an actual form/client step. CF has an internal HTML processing engine, but it's not going to run the javascript internally to do the encapsulation step. We need to make a straight REST call with a way to generate the "nonce" with our ColdFusion engine or at least a JAVA call.
Related
I'm building a website with Django 1.11 with a fairly simple javascript/html/css part (no framework like Vuejs). I have page reload on each navigation which is fine for my use case.
For convenience, I serve my website from App Engine Standard and it's going well so far. Now, I need my user to be able to upload files (up to 300MB size). Due to App Engine's limitation on request size (32MB), I'm using signed urls so I can send these files directly from my client's Javascript to Cloud Storage.
Due to the size of the files, the upload may take some time, but I can't seem to navigate to another page since it may cancel the upload. I understand that for a case like this a client app like single-page app in Vuejs for example would be appropriate but is there a way to achieve this with my current setup without rewriting my whole website (with possibly Vuejs and Django REST API)?
Any suggestions would be much appreciated.
Am I missing something?
But I am really not getting the rationale behind most online blogs and tutorials suggesting to use a base Django template to render a ReactJS bundle (bundled from webpack).
In my mind, the point of using Django Rest Framework in the first place is to completely isolate the frontend from the backend and have something like Nginx serving an html file that would import the ReactJS library (like any other stndard html/js project). The ReactJS layer would then get or manipulate data solely through the DRF REST API.
It is like most developers treat ReactJS as a completely novel beast, when it can be simply treated as standard JS (with added steroids) that runs on the browser.
Can someone therefore explain to me what are the advantages of using the methods depicted by blogs such as Jonathan Cox and Owaislone ?
On one part, you're right. One of React's principles is to make it function like a Mobile app(that consumes REST API) which also compliments React-Native, so there's not much for the programmer to learn and pick up and can quickly develop an app if they are familiar with React. This way, you'd build the back-end to serve both the web app and the native mobile app without much rewriting or customizing.
Usually, people like keeping their code together, front-end and the back-end if they're just developing for the web. It's a common practice. Since Django is widely used and is also an open source framework amongst a lot of web-developers, there's a big community to develop tools or plugins for it. This way, they'd just have one server instance running and configure the backend to serve just the index.html page, and the routing is handled by the browser.
I, on the other hand, prefer the latter part, work on a team with backend engineers and mobile developers. We heavily rely on RESTful calls for our apps. So we keep our code base neat and isolate our backend from our front-end so each of us can work independently.
It's just a matter of preference really, Jonathan Cox and Owaislone both don't preach about the right way to develop React apps, they just demonstrated one of the ways React can be used.
Also, some backends have a lot of security and need to be configured to allow certain headers for making requests. It could make you look at your computer screen for days while you sit there wondering how to work around the problem and you're diving deep into the documentation for web requests. CORS is one of the problems when you isolate your front end and back end code. It's something that can totally be avoided if Django is serving the files.
I'd say you can go ahead and pick one that suits your need, isolate your React code from the backend if you'd want the back end to work on mobile apps too, saves a lot of time.
I am working with phonegap and jquery mobile at the moment. I just want to know whether there is a library that I can use or a way to call SOAP an RESTful webservices to my mobile client.
I did a lot of research and did not find anything that I can use. Do I need to write this from scratch?
Thank you.
First forget about SOAP, at from pure javascript point of view. On the other hand if you are willing you can use Java to create a web service client side code. Next step would be to connect jQuery and native Java part of Phonegap. It can be done easily if you create your own plugin.
Then again if this is a to much job for you there is also another solution. Same function used for jQuery REST call can be also used for jQuery SOAP call. More information can be found in this tutorial. But be warned, you will need to write client side XML. Still this is not that great solution.
On the other hand I would rather choose REST over SOAP. While SOAP is great it creates to much data overhead and we need smallest possible data footprint. Because Phonegap is HTML/JS/CSS wrapper it is commonly used to communicate via XHR/Ajax. So in our case it's better to use jQuery Ajax functions. Here you can find an excellent tutorial.
One great thing about using $.ajax function inside a Phonegap app for REST call is that you don't need to worry about CROSS-DOMAIN calls.
There's also third solution, rather hard but probably best of them all. Instead of using jQuery $.ajax function you should think about using Backbone MVC framework with jQuery Mobile. It will take time to master this combination but from my experience this is No. 1 solution if you want to use REST to communicate with your server.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).
I am looking on advice on how best to approach a new project I need to develop. From the outset I must add, I have 0 experience with Web development on any level.
What I need to do is provide a web interface through the browser which will communicate with a server back end. The data retrieved will be sourced from either a DB or from another source - external device which the server itself will communicate with via IP. The data retrieved from the external device will always be a string format of n length (non unicode) and the DB data will mostly be strings and numbers with the odd blob thrown in (storing a picture). The communication will always go from the Client (web browser) to the Server. I don't believe that the server would need to instigate the comms.
I have Delphi XE, so started looking at using a REST server for communication and I think that seems to be OK. However, from what I can see, I need to create HTML web pages to "render" the data on the web browser. Is that true? Can I use the IW components with a REST server? If so, I'm not sure how to get the data to/from the browser UI. Am I better of investigating Ruby on Rails perhaps? From what I read on a different thread in here, it's based on MVC and some other areas which I feel, design wise, would fit how I would create the application (I was planning on creating the app based on the MVP or similar design pattern).
I think REST makes the most sense, so if the IW components can't be used, are there any 3rd party products I can use which would let me design "pretty" UI html. Given I don't know java script, would that be a stumbling block with REST too.
Thanks and hopefully I have provided enough information.
Thanks
Jason
Will a human being be responsible for typing the data retrieved from your external device into a web page?
If so, and you have no web development experience, Intraweb is definitely the way to go for Delphi programmers wanting to build a web application without learning new skills. For additional components to create a prettier UI I suggest using TMS Software's Intraweb Component Pack Pro.
If you don't need a human being to manually type in this data then you don't need Intraweb at all. Instead you would write a client application which presumably interrogated your external device for the data and then transmitted it to the REST server. Look at the documentation you've used to build your REST server and it should have a section on how to build a REST client.
You can build an ISAPI module with delphi that does the job, or include a HTTP server right into you executable with Indy, ICS or Synapse.
ISAPI will give you the freedom to choose Apache or IIS and give you all their power this way. Embeded HTTP server will give you a nice small application in which you control all ascpects of how it works.
Yes go with REST as it is simple and clean. All you need is to think and design the API (functions that your server will support). You can bind the APIs to the URL schema thus using the REST principle. I would do it simply like this.
A client makes a request. You show some form of GUI (load or render a HTML page with possible javascript)
User makes an action, you call appropriate API (or the user does it directly).
Show the user some result
Just guide the user process through a series of API calls until the result is made
You can use plain HTML and then add javascript if needed (jquery) or you can use ExtJS from Sencha which makes building a nice GUI a lot easier and is very well structured.
I would not use any "WYSIWYG" web tools. Plain old HTML written by your favorite editor is still the king in my opinion.