Have you ever wondered how to debug or play with your cloud code in a comfortable and fast way … without any coding? Because I think it can be a huge pain.

Most probably you already know that Parse Server works very well with the REST API. If you feel the need to interact with the REST easily, you have come to the right place. Let me introduce you to the SashiDo’s API Console, part of our Dashboard. In brief think of the API Console as a simpler version of Postman and so easy to use that you will feel like a magician.

Now I will shed some light on how to use our API Console and shed some more light on:

1. What is an API
2. What is a REST API
3. How to use the API Console in SashiDo’s Dashboard
4. Request types
   • GET requests
   • POST requests
   • PUT requests
   • DELETE requests
5. How to test ACLs and run requests as a specific user
6. How to call your Cloud Code functions
7. How to export the API Console calls to cURL and test them in the Terminal
8. Useful links
9. Fin

What is an API

The ability to link with other programs and devices is an amazing thing. We are all connected to the world and each other like never before. But how does data come from one point to another - from here to there. How does different applications and devices connect with each other to allow us to do different jobs with just a few clicks?
The little-known warrior of our connected world is the Аpplication Programming Interface or API.
It is the engine behind the scenes that we take for granted but it is what makes possible all the interactivity we have come to expect and rely upon. In our context the API is a set of functions that allow the creation of applications which access the features or data of other applications or services.

What is a REST API

One of the most popular types of APIs is REST or, as they’re sometimes known, RESTful APIs. REST or RESTful APIs were designed to take advantage of existing protocols. While REST - or Representational State Transfer - can be used over nearly any protocol, when used for web APIs it typically takes advantage of the HTTP protocol.

Parse Server uses the REST API so basically you can interact with the Parse Server from anything that can send an HTTP request. There are many things you can do with the Parse REST API. For example:

• A mobile website can access Parse Server data from JavaScript.
• A web server can show data from Parse Server on a website.
• You can upload large amounts of data that will later be consumed in a mobile app.
• You can download recent data to run your own custom analytics.

In depth knowledge of how to work with the Parse REST API is available on the official Parse Server REST API Guide.

Now, after you have an understanding of how the Parse Server communicates with the outside world you might want to try some actual requests, be it to get a hands on experience, do a quick proof of concept, or just quickly test something out. You have a few options on how to do it - write client-side code, use a REST client, or simple cURL commands. But that can be a laborious process which takes away valuable time that you could be putting toward designing great experiences for your users. That’s why we made this part of your job easier by providing the API Console.

The API Console in SashiDo’s Dashboard

The API Console provides a graphical UI for exploring your Parse Server API's resources and interacting with it. It has a beautiful interface and is pretty easy to use. You can compose requests, inspect server response, generate client cloud code calls and export cURLs painlessly

You will find SashiDo’s API Console when you enter the Dashboard, choose the app you want to work on, navigate to Core and then you will see the API Console.

Here are a few things you can do with the API Console:

• Create, read, update, and delete objects
• Run requests as a specific user of your app (to test your ACLs and CLPs)
• Call your Cloud Code functions and start background jobs
• Export the calls to cURL to test them in your Terminal or Shell

So, let's go directly to our API Console and have a look there. You can try out some queries and take a look at what the server returns.

When you open the API Console you will find a toggle on the upper right corner, - that is where you can choose whether or not to use the Master Key when you perform sensitive API calls. Talking about sensitive API calls you will find some additional info about the use of Master Key in the Parse official REST API guide in the Security section.

Using the Master Key will give you access to data ignoring all the ACLs and CLPs. If this isn't a requirement for your use case, you can switch off the Use Master Key toggle

Request types

Have you ever asked yourself what is the difference between GET and POST requests, or when to use the PUT request? Having a basic information of how to execute HTTP methods with an API Console is a useful knowledge while exploring and trying out APIs. Let’s look through the different request types.

GET requests

GET requests are the most widely used methods in APIs. You can use the GET method to retrieve data from a server at the specified resource. For example, say you have an API with a classes/Users endpoint. Making a GET request to that endpoint should return a list of all available users.

Having in mind that a GET request is simplest, inquiring for statistics and no longer modifying any assets, it is considered a safe and idempotent method.

Whilst you're developing tests for an API, the GET method will likely be the most common type of request made, so it's essential to test every acknowledged endpoint with a GET request.

POST requests

POST requests are used to send data to the server’s API to create а resource. The data sent to the server is stored inside the request body of the HTTP request.
The simplest example is a “hello message” on a website. When you fill out the inputs in a form and hit Send, that data is put in the response body of the request and sent to the server.

It's worth noting that a POST request is non-idempotent. It mutates data on the backend server (by creating or updating a resource), as opposed to a GET request which does not change any data. Here is a great explanation of idempotency.

Here are some tips for testing POST requests:

• Create a resource with a POST request and ensure a 200 status code is returned.
• Next, make a GET request for that resource, and ensure the data was saved correctly.
• Add tests that ensure POST requests fail with incorrect or ill-formatted data.

PUT requests

Just like POST, the PUT requests are used to send data to the API to update a resource. The difference is that PUT requests are idempotent. That is, calling the same PUT request multiple times will usually produce the identical result. In comparison, calling a POST request many times can have side effects of creating the same resource more than one time.

Testing an APIs PUT request is very much like testing POST requests. But now that we recognise the difference between the two, we are able to create API tests to affirm this behaviour.

Check for the following things when you test the PUT requests:

• Repeatedly calling the PUT request always returns the same result.
• After updating a useful resource with a PUT request, a GET request for that useful resource should retrieve the new data.
• PUT requests will fail if invalid data is sent in the request body, hence the specified resource will not be updated.

DELETE requests

The DELETE method is precisely as it sounds: delete the resource of the desired URL. This method is one of the most frequent in RESTful APIs so it is top priority to recognize the way it works.

If a brand new user is created with a POST request at the classes/User endpoint, and it can be retrieved with a GET request to classes/Users/UserID, then creating a DELETE request to classes/Users/UserID will completely remove that user.

DELETE requests must be heavily tested on the grounds that they normally dispose of information from a database. Be careful when testing DELETE methods. Ensure you are using the precise credentials and no longer checking out with actual user records.

In a normal test case, a DELETE request should look like this:

• Create a brand new user with a POSТ request to classes/_Users
• After the POST request was successful, make a DELETE request to the endpoint classes/Users/UserID
• Next, a GET request to classes/Users/UserID will return a 101 status code, with an error Object not found, in the Results, if the DELETE request was successful.

Test your ACLs and CLPs by running requests as a specific user of your app

You can call a function as a specific user and check if the user has access to the resources you are calling. This is a very easy and simple way to verify if you have correctly implemented the ACLs and CLPs for a certain user of yours. Just enter the username or user ID in the Run as.. field and perform the command you want to receive results for.

Call your Cloud Code functions

Calling your Cloud Code functions has never been so effortless as it is with our API Console. By default there is a simple cloud code function sample in the functions.js file in your Cloud Code and in your Github Repo in the cloud folder so we can use it and show you how you can call a function through the API Console.

You will simply need to go to the API Console, choose the type of request, which will be POST, and choose the endpoint. Select the POST request and the endpoint functions/hello, click on the Send query button and see if the Dashboard shows you “Hello from SashiDo’s simple cloud code” message.

Export calls to cURL

cURL is the most used command line tool for making API calls. It is great for complex operations since it is scriptable and versatile. It combines the command, the credentials, like application ID, REST API key, your desired API endpoint, query parameters and more in a single command.

There is a very easy way to create cURL commands. You can construct a request in our API Console and convert it to cURL using the Export to cURL button. It is that easy. I am sure this will save a lot of your time if you have to write it on your own. For example, if you experience an error with your Cloud Code and you are contacting our Help Desk it is a good idea to run the same request or query through the API Console, export it to cURL and then include it in the steps to reproduce. Our Dev and Engineering team will be happy to resolve your issue in a faster and more adequate manner.

Useful links:

What is an API? In English, please.
RESTful API definition
Command line tool and library for transferring data with URLs
How to protect Rest API key for Parse in html application
7 HTTP methods every web developer should know and how to test them

For easing you even more we have also made a video about the API Console.

Fin

There you go! Now you have some ideas on how you can play around with the API Console or debug issues without writing a single line of code. Now it is your turn to explore it and enjoy the easiness of coding!

At SashiDo we certainly care about our customers and we strive to be up-to-date on the horizon of the novelties coming up. We’re all working on GDPR these days and we want to help people understand what it is.

What does GDPR mean?

In February we announced that GDPR is coming and SashiDo.io is getting ready and now we will be more specific on how to make sure your mobile app is prepared for the upcoming changes in the European Union region.

As the economy becomes increasingly digitized many companies hold sensitive personal data information. They also pick information about various sources to study customers’ behavior. A data is associated with significant risk if it is stolen and abused. Therefore GDPR, General Data Protection Regulation, was introduced to specify how a customer data should be used and protected. GDPR was officially adopted by the EU Parliament in April 2016 following a 2-year adoption process. It will become in force in May 2018 and is applicable to everyone involved in processing data about citizens of the EU, regardless of whether the organization is located within the EU or not.

Nowadays, the digitization of everything around it is growing bigger and bigger and thus our private data is more exposed and available than ever before. A revolution is coming and it is related to the protection of the personal data over the Internet.
Тo supply European nationals with greater security assurance and to guarantee organizations display more noteworthy responsibility, a landmass wide personal data insurance upset was of the substance.

Hence, this May, Europe's information security guidelines will experience a remarkable redesign. The existing Data Protection Act will be followed by the General Data Protection Regulation, a framework that will change how organizations and open part associations handle client personal information - with altogether more prominent fines for the individuals who neglect to keep the new regulations.

The GDPR is intended to bring together information security for all people inside the EU under one umbrella and in addition control the fare of the personal data outside of Europe. It intends to restore the control over personal data to European citizens and inhabitants and to fix the administrative condition in which global business is led. As indicated by the EU's GDPR website, the new regulation will blend information security laws thought Europe, giving people more security and rights.

With this new direction, people will have the privilege to get to their private data held by organizations and businesses. Companies will be obliged to get clear assent from the people they gather data about in addition to conducting better information administration.

Once accomplished, the new control will tie for all organizations holding personal data of people living in the European Union, with no attention being paid to the area where the organization is located. This, of course, remains true for mobile apps too.

Organizations should demonstrate they have rolled out the vital improvements to secure client information or they should confront robust fines for non-compliance - 20M Euros or 4% of their annual profit. Moreover, mobile apps that are non-compliant risk being restricted from the app stores.

We have already started to get ready for the GDPR. We have directed careful research into the new control to pick up an extensive comprehension of the suggestions for mobile apps and SDKs.

We want to spare your time of doing the same by sharing what we have come up to until this point. We will, of course, give updates if there are any changes to our guide as we come closer to May 2018.

It is important to mention some key definitions and their meaning. In this article, we use the words controller and processor quite a lot. What is their meaning? A controller is an entity that determines the purposes, conditions, and means of the processing of personal data, while the processor is an entity which processes personal data on behalf of the controller. For example SashiDo processes both our client’s and their end users data under the highest standards and guarantees for safety and security. Controllers by this means are the mobile app developers that use our platform when creating their functional and beautiful apps.

Here is a guide for preparing your mobile apps for GDPR:

Main requirements

There are some key requirements that you need to focus on:

The right to be forgotten

Under the GDPR, (Article 17) EU citizens have the right to access and control their personal data. Basically, this means that people have the privilege to ask for their information controllers to erase all their personal data, and stop third parties from forwarding it.

Explicit Agreement

As per the new control (Article 9), organizations must demand and get agreement to gather, utilize and move personal data. This must be made, and given, in an definite, clear and simple frame, with no confusing legalese. People must have the capacity to pull back consent as simply as they can give it.

Notifications for data breach

If an organization's database is ruptured, organizations must notify their clients and the authorities within 72 hours of understanding about the leak (Article 33). Data processors should tell the data controllers of the rupture immediately. This is critical, as information breaks could bring about a hazard to the rights and freedoms of people.

A warning to the expert must be "no less than": depict the idea of the personal data break, including the number and classes of information subjects and individual information records influenced; give the data protection officer’s contact information; describe the likely consequences of the personal data breach; and depict how the controller proposes to address the rupture, including any mitigation efforts. If not all data is accessible without a moment's delay, it might be given in stages.

What are the news with us related to the GDPR frame that is about to come soon.For your convenience, SashiDo will implement a new feature in our dashboard. We will add a section where you will be able to add your team members (DPOs) who will be responsible for the GDPR compliance for your company. In case something goes wrong, you will have a faster access to the contacts of the person responsible for notifying the authorities.

Privacy by design

Thought this isn't another idea, under the GDPR, privacy by design will turn into a lawful prerequisite. This implies security and data protection will be required through the whole project lifecycle. According to Article 23 of the GDPR, data controllers must only hang on and process data that is totally fundamental for a project to be finished. In addition, data access ought to be restricted to just those employees responsible for the processing.

Data protection officers

Under the GDPR, internal record keeping necessities and the arrangement of data protection officers (DPOs, workers in control with overseeing information protection) will be obligatory for large-scale tasks. DPOs will be employed for their master knowledge of data protection laws and practices. They will be provided with the assets for performing their roles and will report specifically to the highest level of management to ensure information security.
DPOs must be employed in case of: public authorities, associations that take part in expansive scale orderly observing, or associations that take part in the vast scale preparing of touchy individual information. On the off chance that your association can’t be categorized as one of these classifications, at that point you don't have to select a DPO.

Mobile apps challenges and private user data

Most mobile applications combine parts - SDKs - so as to upgrade their applications with an assortment of capacities. This has turned into a standard in the mobile applications industry, with more than 18 SDKs coordinated in a normal mobile application. Yet, how about we do not overlook that these SDKs are in actuality secret elements of third-party code that app developers let into their application, a code that accompanies the work incapacity to get to private client data at last client gadget.

Recent reports say that mobile apps have at least one SDK trying to access client data like location, the list of installed apps on the users' device, contacts list, accounts, calendar, microphone and other. This data isn't protected by any consent that clients can give or deny, yet is somewhat up for snatches. The expectation is to check for installed apps so they can speak with each other at whatever point conceivable. However, it shows up reality has demonstrated that this data is taken for other reason, for example, offering the information for focused promoting. As of February 2018, Google will begin implementing stricter directions around private
client data access and apps should just access data indispensable to their core functionality or give the client data about the information being taken.

Going back to SDKs, often they needn't bother with client data for their core functionality yet, all things considered, this makes some potential approach for mobile apps concerning GDPR requirements.

As an app developer you can make sure that the SDKs you work with don't accumulate and spare information in their own databases, or on the off chance that they do, they are set up to agree to the GDPR when the last rules are issued.

You can also ensure your SDKs are prepared to guarantee the wellbeing of your clients' information. Incorporate strict classification, information security and information residency statements as required in authoritative concurrences with your SDK suppliers.

Since we have a superior comprehension of the potential dangers mobile apps need to manage, how about we plunge into the particular GDPR tips for mobile apps.

GDPR for Мobile Аpps

The GDPR meaning for Mobile apps

GDPR characterizes "personal data” as the recording of any information that could distinguish a person. Identifiers can incorporate names, telephone numbers, and addresses, and also advanced data, for example, usernames, location. The sky's the limit from there. This control, in this way, influences all organizations somehow, and mobile apps are no special case.

App engineers and developers are totally and specifically in charge of their clients' information. In this manner, app owners must guarantee complete visibility and continuous control over the app use and action. They should first figure out how to get, store, exchange and utilize information, to enhance security. Upgrades to servers and new firewall setups may likewise be fundamental. Developers and distributors must monitor changes inside information, and also digital and physical access to it. This implies an entire history of changes must be archived. Any information that moves between the application and servers ought to be encoded and secured, notwithstanding the sufficient hashing of client passwords.
How SashiDo can help you with this? Well we are save. We store our customers’ data in separate access-controlled databases for each app. If there are multiple apps thee is assigned a separate database per app. We believe this will mitigate the risk of unauthorized access between applications.
The access of the SashiDo’s staff to the operating systems is limited and requires username and key authentication. Our operating systems do not allow password authentication to prevent password brute force attacks, theft, and sharing.

Useful rules for mobile application consistency

To guarantee that information processor can precisely conform to all directions, the accompanying measures must be executed in mobile application configuration, introduces and use.

Determine whether the app really needs all of the data

Just save, utilize and process the information that is totally essential for the application's prosperity, to restrict what can leak and to amplify the odds of getting client assent. This additionally alludes to information moderation.

Inform the client and get assent

Clients should consent to a list of individual information that the mobile app needs to utilize, the time of amid which information is put away and the motivation behind the information use. Clients ought to be informed of any data sharing to third parties (SDKs). Correspondence must be clear and direct. Mobile apps must present clients with agreement forms prior to installation. The assent ought to be particular, communicated through a dynamic decision and unreservedly given. Likewise, it ought to be reached out to the granular assent of each class of users data the application should access and utilize. Assent must be gotten before any information is used or gathered from client's device.
If you don’t have the time to build this solution from scratch there are useful tool like ConsentCkeq that may help you taking the consent of the customers.

React to client demands

Precise data ought to always be given to the client. The choice for clients to address information use, pull back assent (for every classification of individual information) and have their information erased should likewise be effortlessly given from the application. At the point when a client asks for that their information to be erased, there must be no chance to get for information processors to later recover that information, even from backups.

Encrypt user data

Guarantee individual data is encrypted with a legitimate and solid encryption algorithm to limit information outages. On the off chance that information is appropriately encrypted to the point that it is rendered pretty much incoherent, outages would end up futile and organizations would not need to tell clients that their information was hacked.

Guarantee clients are refreshed about security episodes

Clients (and the national supervisors specialist) must be kept on the up and up about security ruptures and information leaks. This gives clients the chance to ask for information deletion and the experts the capacity to find the source of the leak.

Know your technology

Constantly evaluate the application's current situation. Guarantee that activities that will render the application rebellious are ceased. What's more, you should take care to keep the application from sharing personal data to an outsider in a way that could open the application to data leaks. In the event that SDKs have been executed inside the application and the SDKs endeavor to get to the personal data the application distributor is as yet in charge of the information gathering and use. Approving the consistency in each angle that goes into the application winds up basic under the GDPR.

Checklist

Ensure you have everything covered with the following checklist that summarizes all of the mentioned above to set up your mobile application for GDPR consistency

1. Go throughout the information you are asking for from clients and decide whether all is totally essential for the application's prosperity. Use data that is totally essential for the apps’ needs.
2. Adjust application flows and screens on the off chance that you have changed the amount and type of information you are gathering.
3. Make a list of all sorts of agreements you need to receive from your clients.
4. Choose if you need to request each kind of assent independently or all together.
5. When you choose to request assent independently, ensure you request each assent at the proper time and place in the client’s stream for a limited interruption.
6. Add an option to your application for clients to get in touch with you with inquiries concerning their personal data.
7. Add an option to your application for clients to pull back their assent per information classification.
8. Add an option to your application for clients to have their information erased forever from the application.
9. Settle on the ramifications of application utilization for clients who pulled back assent or requested their information to be erased.
10. Guarantee erased information cannot be recovered by you or outsiders that entrance the application not even from backups or servers.
11. Ensure the information you are gathering is legitimately encoded, isolated and secured to limit information leaks.
12. Build up a system for rapidly informing the clients and authorities for information leaks (email, push notification or other).
13. The notice component ought to likewise incorporate the capacity to offer help and answer clients' inquiries following an information leaks (FAQs, talk bolster and other).
14. Build up a checking procedure that can distinguish a potential noncompliant action as soon as could be expected under the circumstances, so it can be ceased.
15. Ensure that SDKs (or some other outsider) you work with are 100% consistent with the GDPR and screen this continuously to recognize potential problems at the earliest opportunity to maintain a strategic distance from dangerous exposure.
16. Set up authorization and checking measures for every one of the arrangements and procedures you produce for GDPR consistency.
17. On the chance that you have EULA, ensure every one of the progressions and consistent forms are conveying appropriately.
18. Consider adding a GDPR specialist to your team members.

An actionable solution for third-party SDKs

As GDPR authorization day moves closer, mobile application engineers must manage outsider (SDKs) merchant who can get to their clients' information. Any outsider or associations who will use the clients' information must be recorded in the agree frame as indicated by GDPR rules. This is on account of the controller who is completely in charge of the availability and direct of the processors that store or utilize an EU citizen’s personal data.

Application developers need to mitigate the risk and remain responsible for the SDKs they work with. Here is a powerful method to deal with the fundamental issue secured:

1. Recognize and study all SDKs you are working with to comprehend what information is gathered, put away and handled, how well each SDK secures individual information and how they are functioning towards getting to be GDPR consistent.
2. Out of the information gathered by the SDKs you are working with, figure out which information is without a doubt vital for your application to work.
3. Work with the SDK organization to take out all the gathering of superfluous information.
4. Ensure the SDK has satisfactory safety efforts to guarantee the security of your clients' personal data.
5. Comprehend the correct way the information takes amid the handling lifecycle to guarantee satisfactory security is executed at each stage.
6. Incorporate strict classification, information security and information residency conditions in any agreement drawn up with a SDK.
7. Use instruments to screen, control and oversee dangers related to the SDKs you work with.

Need additional info about GDPR?

It is available on the following links:
GDPR FAQ
5 steps to becoming GDPR compliant on mobile apps
What does the EU GDPS mean for your app
The GDPR and mobile application protection
What does GDPR mean for Mobile App Owners - 12 use cases
WTF is GDPR?
GDPR, Sentry, and You
The complete guide to everything you need to know & do to comply
GDPR Email Copy

You are also welcome to contact us over the live chat or send us an email at support[at]sashido.io.