At the company I work for, we are developing two different systems. These systems will exchange a few information. We thought to make them communicate through Rest paradigm. Now the trouble is that these informations must travel in a secure way (encrypted). I read that Rest is indipendent from the security, then i would want ask you some suggestion about this problem.
Thanks a lot.
REST is an architectural style. It makes as much sense to say you thought of communicating through REST as it makes sense saying you want to connect two buildings through Spanish Colonial.
What you probably mean is that you want to make them communicate through HTTP. If you want the information to be encrypted, just use HTTPS and basic authentication on every client-server interaction.
Related
I'm currently learning different building blocks of blockchain and the different services, applications that currently exist. In a lot of wallet applications, I've seen them implement a DApp Browser, which lets their mobile app directly communicate with the DApp without the need to leave their application.
I understand how they show DApps on their homepage, but the main doubts I have are surrounding how the application communicates with the browser.
I've been going through Metamask's mobile application github repository to understand the flow. They included a diagram too on how the architecture but it has been overwhelming to jump into for the most part. Although I've got a bit of an idea of the flow, the main question of how the browser and application interacts is still not clear.
If there's any article, or if you have an idea I'd appreciate the help.
The Metamask documentation can be found here: https://docs.metamask.io/
Frequently, a wrapper is used, such as onboard.js (https://docs.blocknative.com/onboard) or web3modal (https://web3modal.com/), which allows for non-injected wallets to be connected. Personally, I prefer the UI of onboard.js, but plenty of people use both. I highly recommend you use one of them.
Finally, typically one doesn't interact with the window.ethereum provider directly. A library such as ethers.js (https://docs.ethers.io/v5/) or web3.js (https://web3js.readthedocs.io/en/v1.7.4/) makes writing DApps a lot easier. I personally prefer ethers.js as it is more strongly typed, but again, both are very commonly used.
This might be a silly question on this site, but I want to learn more about it.
Being in the Software Engineering field, I have come to know that it's useful to get acquainted with Web-Services. I am trying to understand it. To do so, I must know the difference between a Web-Service and a Application-Service in simple terms.
I have heard about SOAP & REST Services.
For a newbie like me, its overwhelming to understand these concepts when I search them in Google.
How to understand these things better and in what order?
I think it's a great and simple question which usually confuses most of developers. What is Application Service and what is web Service?
Web service is a common term which you can find easily on the internet. Although some time they cross each others boundaries but here is a simplest explanation I can think of:
Application service or Application Layer is an abstraction layer reserved for communications protocols and methods designed for process-to-process communications. Application layer protocols use the underlying transport layer protocols to establish host-to-host connections.
Some time you can also use Application Service to define method calls within your application.
WebService: Any application or method which can be accessed by web is a Webservice. You can also say: anything available on the web is WebService.
There are three common web service architectures:
RESTful resource-oriented,
RPC-style e.g. SOAP
REST-RPC hybrid. 90% of the web sites use this unknowingly e.g. http://mysite.com/get/pictures?tag=birthday :)
I am in the process of designing an application that users will be able to log on remotely and use - via a web interface.
Security is of paramount importance (think credit card and personal banking type information)- so I need to make sure that I get the security aspect nailed down - HARD.
I intend to provide the application functionality via traditional (stateful) web pages , as well as web services.
For what its worth, I am intending to use web2py as my web application framework.
Is there a list of guidelines I can follow to make sure that I have all areas covered?
One stop shopping: https://www.owasp.org/index.php/Main_Page
Read that and take every suggestion to heart.
you should consider at least the following:
authentication. getting users to log on in some manner. which authentication method they use depends on what you aim to provide
privacy. making sure the information they send is only visible to them and your application and not an eavesdropper.
in the simplest case SSL can take care of both of the above. it will always provide encryption but can also be used to authenticate or at least make some simple authentication mechanism more secure. one thing to look at is security of ssl. ssl is suceptible to a man in the middle attack particluarly when the users already have a trust relationship with, say, their employer - who can them proceed to install an ssl gateway which is effectively a mim.
authorisation. making sure users are only allowed to see what you want them to see and no more.
this really depends on technology you are using.
non reputidation. making sure the user cannot dispute the actions they perform
this is a very open ended question. legally this is seldom (never?) used so it depends... something like signed logs of user requested actions for example is probably enough.
Your biggest threat, by far, is writing server-side webapp code that introduces vulnerabilities in your web application layer. This is not something you can checklist. For a starter, make sure you are 100% comfortable with the items in the OWASP Top Ten and understand how to code safely against them. If you are not expert in web application vulnerabilities, strongly consider hiring someone who is to help review the web layer. At the least, i would consider contacting a security testing company to perform some form of penetration testing, preferably with a code review component.
If you ever do anything with credit card data, you will need to comply with the PCI DSS which will require at least quarterly remote-testing from an Approved Scanning Vendor.
SO I am about to write a REST API with Django using django-piston but my employer just wanted to be able to retrieve and create data, so I was wondering what is the difference between:
just creating methods to set and retrieve data and making them
publicly available (of course with authentication and validation in
place)
creating a REST API for the purpose of creating and retrieving data
?
Thanks in advance!
Your second point is basically a sub set of your first point. REST is just a set of methods to create and retrieve data. It is however a fairly standardized set of methods using HTTP verbs instead of different urls to declare what you are trying to do.
So instead of /comments/new/, /comments/delete/, /comments/update/, you would just have /comments/ and POSTing to create, PUTing to update, and DELETEing to delete.
I also agree with Zach on TastyPie for what it's worth.
The two key alternatives to "RESTful" would be traditional html forms or a more formal RPC protocol thats implemented on top of HTTP, like XML-RPC or SOAP.
The main advantage of the former is that it can be invoked through a web-browser with no client code at all; but unless the application is designed in a thoughtful way, it's often quite difficult to drive such an interface from a custom client; which must often set cookies to do authentication and specify arguments that it isn't interested in. There's no notion of data types for this kind of API either, everything is text.
The latter has the advantage of getting you up and running in no time at all; You can just write normal functions in python, with a decorator, and they are available for clients that have the appropriate client libraries. The main disadvantage is also that this usually requires the client have such a library. Things like soap or xml-rpc are not typically an option for in-browser applications, or on resource-constrained devices.
RESTful is a sort of middle way that combines many advantages of both. Since the semantics are defined purely in terms of HTTP, any client capable of issuing HTTP can use a RESTful API. HTTP is much more flexible than plain old web forms, usually in terms of giving a Content-Type to the request or response that supports the needed structure. Unfortunately, there's not really a single standard defining how RESTful clients or services should represent their data, so there's necessarily a bit of customization on both ends to get things to work in the best way. Sometimes the flexibility means that you spend more time getting the api just right then you would have had to if you used a different interface, but it often leads to a thinner and yet less leaky abstraction.
There are a few standards or de-facto standards that are also good models of RESTful interfaces, such as json-rpc and the Atom Publishing Protocol.
I thought to practice SOAP API. I know it is a time for REST but I thought to give a try to SOAP. I somehow got Flickr.com API supporting SOAP but it has very difficult documentation. No, working examples are available.
Q1. So, do anyone know where I can learn SOAP. Do anyone has SOAP working example for Flickr API
Q2. Any service other than Flickr providing SOAP interface. I saw Google search api has closed new request for SOAP.
regards
SOAP has been largely superseded by REST on the public Internet - as you have noted in your question and has been alluded to in comments.
There are still large users in the Intranet context, companies with an installed base of SOAP, Service Bus, and other concepts that you may well come across if you end up working at one of them. (There are still CORBA users out there also!) When you control both ends of the application, you may have less reason to be flexible using REST.
So if you are looking for useful public implementations you are mostly out of luck.
That said: do create your own services and try them out on your own. Define a service and implement it. Create a client in a different language. Create another client in a third language.
If you are looking for an educational experience, this will lead you down some of the same paths that has lead to REST use in wide-scale disparate systems (and may also shed light on why the public/private has split the way it has)
Good Luck