Hello dear reader. This is my last blog for my Software Construction and Design and as a very important part of development I choose to talk in this blog post for REST API.

REST API stands for Representational State Transferee and provides a lighter weight compared to SOAP. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations, additional information needs to be provided. Most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP verbs (GET, POST, PUT, and DELETE) to perform tasks.
REST-based Web services output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can keep the output you need in a form that’s easy to understand and use within the language you are using for your application. The information you receive when using REST is a JSON formatted document containing the information you asked for. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.
In most of the part REST is easier and more flexible to use. To use REST you do not need to purchase any tools, Postman or Insomnia can be downloaded for free. REST though, is efficient as it uses the small message formats and it has a fast process.
There are some very strong reasons that you should be using REST. First, REST is the most popular choice of programmers to build APIs.  Also REST API is great on making the data available as a resource as opposed to service.
To create a REST API, the following six architectural constraints are needed: 1. Uniform interface, which means that the same resource should not have more than one URL; 2. Client-server separating, which means that the client and the server should act independently. 3. Statelessness, which means that there should never be any server-side sessions; 4. Cacheable resources, means that the server responses should contain information even though the data sent might or not be cacheable; 5.Layered system, which means there might be different layers of servers between the client and the server that returns the purpose; 6. Code on demands, which means that the response can contain code that the user can execute.

If I also refer to the previous blog about SOAP API I would say that there are clearly good reasons why REST API is a better choice to use when requesting/ expecting data and when you want to build your own program. However the decision is yours. I hope I have helped your CS journey. Till next time…

https://en.wikipedia.org/wiki/Representational_state_transfer

From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.

As I take my final step towards my journey in software C.D.A. this blog would be the last one regarding my journey with learning and researching topic related to my class Software Construction Design and Architecture. For this blog I will be talking about the blog “API management with Kong” by Alexander Melnyk. This blog is about the importance of API management and why does it matter. It also focuses on the Kong Architecture.

In the blog it explain why API management matter. The idea of API management is that it plays an important role when it comes to integration. Which can be done “by providing clear boundaries and abstractions between systems”. The blog also explains a few “ways to tackle the technical complexity and how Kong API gateway can help deal with it”. You may be wondering what is Kong it is an open source API gateway to manage RESTful APIs.” However the blog gives a better description of what and how it is use for. There are five components of Kong architecture:

1. nginx – “The core low-level component” also the most popular used web server.
2. OpenResty – “a web platform that glues nginx core, LuaJIT, Lua libraries and third-party nginx modules to provide a web server for scalable web applications and web services.”
3. Datastore – is a component that “uses Apache Cassandra or PostgreSQL to handle the storage of the configuration data, consumers, and plugins of all APIs.”
4. plugins – “are Lua modules that are executed during a request/response life-cycle. They enrich the API gateway with functionalities for different use cases.”
5. RESTful admin API – It is used to manage the API and provide an important tool to automate developers workflows.

The blog goes on and covers the Kong API gateway in action which “will show you how to create a minimal infrastructure for Kong API gateway. Then I will add an API and a security plugin to restrict the access to a specific user.” and then covers the consumers and plugins. If you have found this topic interesting or if your curiously left with question click on the title link above and read the blog the blogger does a much better job at explaining and getting the message across then I do.

Personally I really enjoyed reading the blog because it helped me realize that the Kong Architecture is in fact very useful and important. I also found the blog to be well written full of useful and important information that will benefit me as a software developer.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

For this week’s blog, I am choosing test-driven development what is and what it is not by Andrea Koutifaris.

Test-driven development(TDD) is a software development process that relies on the repetition of a very short development cycle. First, developers write a failing test case then produces the minimum amount of code to pass that test and finally refactors it to acceptable standards.

There are three processes that are often described using TDD: Red/Green/Refactor cycle.

Red phase

In the red phase, you write a test that uses a piece of code as if it were already implemented. Without implementation and not thinking about production code, this phase is where you concentrate on writing a clean interface for future users and where you design how your code will be used by clients. The Red phase is the most important phase and it is the rule that makes TDD different from regular testing. You write tests so that you can write production code and not test your code.

Green Phase

For developers, the green phase is probably the easiest part of a TDD. This is the part where you write code but not the whole implementation, just enough for the test to pass. Make all the alarming red on the test report becomes green. In this phase, you do not need to worry about violating best practices since we will do that in the Refactor phase. This phase exists to make your task simpler and less prone to error.

Refactor Phase

In this phase, you are allowed to change the code while keeping the tests green. But there is something mandatory, that you have to remove code duplication. In this phase, you can worry about algorithms and such to make the program better. This is the phase where you can show off your skills to your users.

 

I really liked reading this blog and I kind of liked the idea of Test-Driven Development. I think doing it this way creates more code coverage and thus fewer bugs later on. This kind of development is a bit unique to me since I have only done behavior-driven development so far. Test-driven development changed my mind in a way. I think that doing test-driven development is more beneficial, kind of like reverse engineering, we start from something that we know is gonna work then proceed from there.

 

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Source: https://www.guru99.com/mutation-testing.html

This week’s reading is on mutation testing. It is stated to be a technique that changes certain statements in the source code to see if the test cases are able to find the errors. The overarching objective of mutation testing is accessing the quality or robustness of the test cases. These mutations are generally placed in several categories, operand replacement, expression modification, and statement modification. For operand replacement, an example would be simply replacing a variable in an if-statement with a constant. For expression modification, an example would be to replace a less than or equal to operator to a greater than or equal to operator. Lastly, for statement modification, an example would be simplify deleting lines of code, adding code, or modifying data types in the program. This type of testing allows the testers to uncover errors that would have remained undetected. By comprehensively testing the tests, it will provide a large amount of code coverage of the source code. It is a very useful white-box testing technique.

I found that the article provides great depth on mutation testing, steps on how the technique works, advantages, disadvantages, and provide examples. This serves as a great refresher to the activity done in class. Before that, I would have never thought about a software technique that provides such coverage to the tests already created. I can agree with the article that it is powerful tool that brings adequate amount of error detection. It will improve code quality and early bug detection will save costs later on in development if they are caught early using mutation testing. What I found most interesting about mutation testing in general is the mutation score. It is defined as the percentage of killed mutants with the total number of mutants. By observing the percentage of killed mutants, we can see if the test cases are effective against the mutations. Unlike other white-box testing techniques, it is a very unique way of effectively testing tests for their techniques. This is similar to the black-box testing technique fuzzing, where it creatively creates unexpected creative inputs for software to uncover bugs that would have otherwise been missed. In conclusion, this exhaustive technique is very useful for comprehensively testing a program and is very effective.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

When we think of AI, we usually think of robots doing certain actions that can replace basic human actions. Sometimes these actions aren’t basic at all. Development timelines have also changed drastically. This Forbes article talks about how AI can potentially take over testing phases due to the shorter time-frames for gold standard releases. With more and more companies releasing software, there will naturally be more competition. Not only is the competition driving this push for AI software testing, but also efficiency. Another thing that drives a push for AI software testing is cost structures. A lot of companies are based on certain cost structures which can heavily impact the quality of a product. With the amount of testing needed for a product to be in working conditions, you may need a lot of people per team to test software. Software testing AI seeks out to have this issue resolved or at least assisted. But, the main reason that AI in software testing is mainly due to narrow constraints of time. Since deadlines are always being set shorter and shorter while standards are being set higher and higher, it seems like the logical solution is to find the easiest and most effective way to combat these restraints

This is an interesting topic because it’s something that you wouldn’t really think would make much sense. If you development an AI to test software, then this could still potentially leave the software vulnerable to bugs. This is due to the fact that there are added variables and “middlemen” added into the equation if you have automated testing. Now, not to say that AI testing is useless, as it is probably extremely efficient at testing a lot of smaller things at once, however it seems like it could be added overhead. New roles would have to be assigned for teams just to test the software for the AI that is testing the software. In concept, AI testing seems like a great idea. However, there are bound to be bugs and whether or not it is worth the risk and cost to implement AI software testing is ultimately up to the companies do it. It is a very unique topic and will be interesting to see just how companies will implement this in the future.

Article: https://www.forbes.com/sites/forbestechcouncil/2018/12/17/ai-in-software-testing-will-a-bot-steal-your-spot/#63c50ce36710

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

In recent times, it seems as though a few companies are letting major security flaws slip through their developer tools. A few days ago, Facebook had a massive 8+ million user exposure due to a flaw in their Photos API. This bug allowed photos of users using certain apps with this API to have their data leaked and pulled without their knowledge. Facebook didn’t realize this until 12 days after this had occurred. Now, Google is in a similar boat. A few days ago, on Monday, Google revealed that it’s Google Plus social media network site (that was in the process of shutting down) also had an API bug that, again, exposed the information of users. This time on a much larger scale. Google’s API exposure hit over 51 million users. Interestingly enough, this happened just two months after they had discovered another bug that exposed data of 500,000 users. This was the initial reason for Google Plus to ultimately shut down. Although Google reported that there was no evidence of this data being “misused”, this information is still out there and the attention will surely seek the eyes of many who will misuse it.

So why is locking down an API so important? An API is a predefined set of tools that are used by developers to perform multiple actions in program. A lot of these are protocols that either pull certain information or perform various tasks. The API is the middle ground of how software can talk to each other. When there is an API bug, this can lead to information that is not suppose to be able to be pulled, get exposed to fields that should not be able to. This was the case with Facebook’s Photo API, and now the case with Google’s Google Plus media API. What we can learn from this is, whenever you are modifying or testing with API’s, always make sure that boundary tests are in place to make sure that certain data can not be pulled by any alternative means. Most of the time, only authorized developers are only permitted access to certain API’s, nullifying any outside attacks. However, if an API does not have the correct stops and security in place, user data is at a massive risk as shown by these two examples of mass user data exposure.

 

Article: https://www.softwaretestingnews.co.uk/17470-2-google-plus-closure-api-bug/

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

And the biggest question if the software testing is manual testing vs automatic testing? Why do we need automated testing?

@All Welcome to my last blog post for my Software Test class. As a last blog post for this class I wanted to talk about the Automated Testing.

From the name we can tell that Automated Testing is automated. Automated testing is done through an automated tool, which is needed in exploratory tests and in maintaining test scripts while increasing overall test coverage. Automated Testing is usually used for large projects that require testing the same area lots of times.
Automated Testing has its own implementing strategy which consist in the shape of a pyramid. This strategy calls for automating testing at three different levels. The biggest percentage of this test automation pyramid goes to unit testing. The is followed from API testing and UI testing.

Software tests have to repeated often during development cycles to ensure quality. Every time the source code is modified, software test should be repeated. From my experience at my work, we recently automated the testing and deployment process for one of our systems. For every deployment, we had to test every connected system. One of the benefits of Automated Testing is that is much faster than the manual testing and it also can reduce the time to run repetitive tests all the time. In my opinion time savings equals cost savings. Another benefit of Automated Testing is it increases the test coverage.  It can easily execute thousands of different complex test cases during every test run, providing coverage that is almost impossible with manual testing.

https://www.qasymphony.com/blog/test-automation-automated-testing/

Kyle makes a good point in explaining the differences between the test automation and automated testing as its important to know the difference.

From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.

https://www.softwaretestinghelp.com/what-is-mutation-testing/

This blog post explains mutation testing with a simple example. Mutation testing is a fault-based testing technique. Variations of a software program are subjected to the test data set to determine the effectiveness of the test set in isolating deviations. The example that this post uses involves a hospital site that lets new users register. The input to the program is the age of the patient. If the age is greater than 14, a general physician is assigned as their main doctor. The example data set for the tester is 14, 15, 0, and 13. The goal is to check if this data set is adequate to identify all possible problems with the code. To achieve this with mutation testing, variations of the program (mutants) must be created. A mutant is nothing more than a deviation that contains a self-seeded fault. Example mutation operators are:

• Arithmetic operator replacement
• Logical connector replacement
• Statement removal
• Relational operator replacement
• Absolute value insertion

Once all the mutants are created they are subjected to the test data set. If the data set kills all mutants, it is effective. If it does not, more or better test data should be used. Each value in the data set does not need to kill all mutants, but all the values combined should kill all mutants.

Some mutants are not useful at all. Mutants to avoid include:

• Syntactically incorrect mutants
• Mutants that do the exact same thing as the original program
• Mutants that can be killed by any data set

The number of mutants can be extremely large, even for a small program. Because of this, a subset of mutants is normally used and the mutants are commonly chosen at random. If there are some mutants alive at the end of the test, it is either an invalid mutant or the data set was inadequate. Mutation testing is a structural, white-box and unit testing method.

This was a useful post because it explained mutation testing with an example that was easy to understand. It also covered all of the important information to know about this testing method. After reading this I feel like I have a much better understanding of what mutation testing is and why it’s used.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

For my final blog post of the year, I wanted to select a more interesting topic. The article Two-Factor Authentication with Node.js by David Walsh covers two-factor authentication and shows how it works behind the scenes using JavaScript. He even includes examples of how to implement two-factor authentication using QR codes.

Two-factor authentication is a user-verification method used by many web applications and services today. When a user tries to log in, a verification code is sent to a previously specified external device or address, such as a phone number or email. This code usually expires after a set time. The user that requested the code then enters it in the application or program to verify themselves and gain access to their account. By splitting access to your account into multiple different forms, you greatly increase the security of your account. Nobody can log into your email, even if they know the password, if you have two-factor authentication that is being sent through SMS.

David Walsh explains how the system of two-factor authentication is divided up behind the scenes. The first step is to generate a secret unique key for the user to validate two-factor authentication codes in the future. Then, you must add the site to your authentication. Finally, this code must be provided by the user and then validated to confirm it matches what was expected. If not, the user can try again with a new key. Since most two-factor authentication services refresh the key every few seconds/minutes, it is not necessary to lock the user out if they get one wrong.

Two-factor authentication is an incredibly powerful and important new form of security that allows you to put an even tighter lock around your information. As a developer, it is important to consider allowing your users to use two-factor authentication for your application, especially if any sensitive data is stores or if access to your account leads to vulnerabilities in the system. It’s one of those things you don’t realize is so important and valuable until you get your account stolen and realize it could have been prevented.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.