Author Archives: erockwood

More On APIs

This week I decided to dive more into APIs in general, not just RESTFUL APIs. So let us start at the beginning. API stands for Application Programming Interface, and it is an interface with a set(s) of functions. These functions allow programmers to use specific features or data of an application. A web API is an API that is accessed over the web, like through the HTTP protocol. The web API is a framework that assists in creating and developing HTTP based services.

An API usually works as follows, the client application initiates an API call, usually to retrieve information. This call is also known as a request. This request is then processed from the application to a web server using the API’s Uniform Resource Identifier, and usually has a request verb, like GET or POST, for example, headers, and a request body. After receiving a valid request from the application, the API makes a call to the web server. The server then responds to the API with the requested information, and the API then transfers the data to the initial requesting application.

APIs are often used for many reasons. This includes, but is not limited to, improving collaboration, offering easier innovation, data monetization (as money makes the world go round), and added security. APIs enable integration such that platforms and other applications can easily communicate with each other, allowing easier automation, therefore improving collaboration. They also offer flexibility, allowing connections to new businesses and reaching new markets, offering easier innovation. APIs are also often offered for free, usually initially, to allow the developers audience to grow so they can build relationships with their audience of developers around their brand for the future, securing future business partners, thus offering data monetization. Lastly, APIs create an added layer of security between your data and a server. Developers can also choose to add further security measures like tokens, signatures, and Transport Layer Security encryption, just to name a few.

There are also many types of APIs, some of which include, but are not limited to, SOAP, or Simple Object Access Protocol, XML-RPC, which is a protocol that relies on XML to transfer data, JSON-RPC, which uses JSON instead of XML for its work, and REST, which we have covered in prior weeks blog posts.

Source:

IBM

I decided to use the above source for this weeks blog post because they provided a ton of good information about APIs in general, and IBM is also a very well known company and therefore also a good reputable information source.

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

More on REST APIs

REST APIs have become increasingly popular over the last few years, and for good reason. REST has less of a learning curve than other API models, has a smaller footprint, and parsing of JSON is less intensive than traditional XML parsing. There are a few key standards to REST, including utilizing certain requests like GET, POST, PUT, and DELETE, for example.

When a call is made using REST API, there are a few things that go on within the call itself. First are the endpoints, which is a unique URL that is used to represent objects or groups of objects of data. Every API request has its own endpoint. In addition, there are also the methods used for the request. These include those I listed above, like GET, POST, and PUT. A header contains the information that represents the metadata associated with the REST API request. The header also indicates the format of the request and the response, and provides information about the status of the request. Lastly, the request also consists of data, which is also referred to as the body, that is usually used with the POST and PUT commands and contains the information that will be updated or created.

Another important part of REST APIs are parameters. When someone is sending a REST API request, they can use parameters to narrow or further specify their search request. These are valuable tools, since it allows you to filter the data being received in a response. Some parameter types include path, header, cookie, and the most common, query. Query parameters are located at the end of a URL path and can either be required or optional. This can be useful if, for example, you are using a base GET command to get all of the objects in the database, and you can have an optional parameter to specify which of all those objects you want, using something like ID or name, depending on your implementation.

Source

I chose the above source because it gave good additional information on REST APIs, compared to other websites I visited. This helped me further understand how REST APIs differ from other web APIs, and what helps make REST different and usually better. REST APIs definitely have their many uses, and allows ease of use with their standards of requests, using easy to understand methods like GET, POST, and PUT, to name a few.

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

REST APIs

REST is an acronym for Representational State Transfer, and is an architectural style for distributed hypermedia systems. There are guide principles and constraints that need to be met for an API to be referred to as “RESTful”. In total, there are six principles/constraints for the REST API. These include Uniform Interface, Client-Server, Stateless, Cacheable, Layered System, and optionally Code on Demand.

Having a uniform interface allows one to simplify the overall system architecture, and helps to improve the visibility of interactions. Within this principle of uniform interfaces, there are four constraints that must also be met to be RESTful. These include identification of resources, where each resource must be uniquely identified, manipulation of resources through representations, so that resources must have a uniform representation in the server response, self descriptive messages, where each resource representation should have enough information to describe how to process the message, and hypermedia as the engine of application state, where the client should only have the initial URI of the application, and the application should drive all other resources and any interactions through the use of hyperlinks.

Client server is much simpler, as it only refers to the separation of concerns, so that the client and server components can evolve independently of each other. This allows one to separate the user interface from the data storage, and allows independent improvement of each without interrupting the other.

Statelessness refers to each request from the client to the server containing all of the necessary information required to completely understand and execute the request. In addition, the server cannot take advantage of any previously stored context information on the server.

Cacheable refers to a response needing to implicitly or explicitly label itself as cacheable or non-cacheable. If a response is marked as cacheable, then the client application can reuse response data later for any equivalent requests to help improve overall performance.

A layered system allows the architecture to be composed of many hierarchical layers by constraining the behavior of the components. For example, each component in a layered system cannot see beyond the layer that they are interacting with.

Lastly, REST optionally allows for client functionality to extend by downloading and executing code in the form of scripts. By downloading this code, this reduces the number of features that are required to be pre-implemented in the server.

Source

I chose the above article because I wanted more information on what it meant for an Application Programming Interface to be “RESTful”. The above article went above and beyond what I could hope to find and provided a lot of information on exactly what it meant for an API to be RESTful. Because of it, I now know exactly what it means for an API to be RESTful.

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

Microservices Architecture In-Depth

Microservices architecture is a newer type of architecture that has become popular within recent times. This architecture differs from common architectures like monolith in that microservices “is an approach to developing a single application as a suite of small services, each running their own process and communicating with lightweight mechanisms.” To better understand the microservices architecture, it can be useful to compare it to the classic monolith architecture. In the monolith, there is one single unit, one central server, if you will, that does everything. One of the biggest problems with this design is that if anything needs to be done with the server, like maintenance or something goes wrong and the server goes down, the entire system gets taken down as a result of being one big unit. Microservices fixes this by having many small units/servers running almost independently of each other, so while some may rely on others for some information, if one part goes down for whatever reason, it does not take the entire system down with it.

A good example of how a microservices operates in comparison to monolith is say, for example, we have two main servers in our system, one for the admins, another for the standard users. This way the admins have their server and database, while the users have their server and database. This way, if maintenance has to be done on the admin server, whether it is updating database schema or whatever it may be, this can be done without affecting the standard users, as their server and database are separate from the admin’s server. This is nice as it can limit downtime for the users, so maintenance can be done on the user’s server only when absolutely necessary to limit outages.

Microservices architecture also puts a big focus on failure detection, and trying to automatically restore the service if it goes down. These services are built in such a way that allows early error/failure detection, so that fixes can be put out as fast as possible. Microservices are also built with upgradeability and scalability in mind, so that as a service grows and requires more and more processing power, it is easy to add more servers to add the extra power needed. With monolith, for example, this requires getting a whole new stronger server, rather than just adding another server, since the monolith is ‘all-in-one’, it does not allow the easy upgrading that microservices allows.

Source

I chose the above source from martinfowler.com because we had some readings from that website earlier in the course, so since they had an article on microservices I though what better site to use than them. They also provided a lot of good information on the topic with clear and concise explanations of the topics.

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

Docker, and why it is so important

Docker is a relatively new way of software delivery. With Docker, all that is needed is the image for the dependencies and software needed, and Docker does the rest. This is huge as before you would need to download and install specific versions of software on each and every computer you wanted to work on, but with Docker, you say you want X, Y, and Z and Docker does the rest for you, making life much easier.

The way Docker does this is through what are called “Containers”. Containers allow developers to package an application with everything that it needs, like dependencies and libraries, and then ship it out as one package. This is where the magic happens, as it means that the application will run on any other machine regardless of any customized settings that machine may have that might differ from the main machine that is being used for writing and testing the application. Docker is, in a way, like a virtual machine in this sense, but instead of running an entire virtual operating system, Docker allows applications to run the same kernel as the system they are running on, and only needs applications to be shipped with things not already on the host computer, instead of having to send out everything. This translates to a big performance increase in the speed of the application and reduces the overall size of the application as well.

Docker is also open source, one of the most important things, in my opinion, software can be these days. This means that anyone can contribute to Docker and modify it to their own needs if they need something Docker does not provide by default. This also means that since anyone can modify it, they can also see the inner workings and ensure that nothing is going on that’s not supposed to, like recording private information to sell to advertisers, for example. Docker makes life easy for developers, allowing them to not have to worry about the system that their program will be running on. Docker also gives flexibility in it’s containers and can reduce the number of systems needed for the program to run.

Source

I choose the above article because it gave a good look into what Docker is and how it is useful for software development in today’s world. It explained the key aspects of Docker and what they are useful for compared to past methods. In addition, the article gave a good analogy to Docker by comparing transporting cargo prior to the standardization of using shipping containers to make transporting good easier, as that roughly translates to what Docker does with their containers.

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

Week 6

The blog I decided to read this week is UML Diagram Types. As we learn more about UML, it is important to know about the many types of UML diagrams. There are two main types of UML diagrams, Structure and Behavioral. Structure types include Class, Component, Deployment, Object, Package, Profile, and Composite Structure Diagram, while Behavioral types include Use Case, Activity, State Machine, Sequence, Communication, Interaction, Overview, and Timing. The main difference between Structure and Behavioral diagrams is Structure shows what is in a modeled system, while Behavioral shows the behavior, or what is supposed to happen in the system.

Of these diagrams, we have worked with the Class diagram. These diagrams are used primarily for Object-Oriented situations. This is because they show the classes along with their attributes and operations of each class. Component is another type of UML diagram. These, as the name implies, show the structural relationship of components in a particular system. Deployment diagrams are used to show the hardware of a system and the software used with that hardware. These diagrams are useful when you have software deployed across multiple machines. Object diagrams are very similar to Class diagrams, however Object diagrams use real world examples. Package diagrams are used to show dependencies between different packages in a particular system. Profile diagrams are relatively new to UML, and are used to profile things like stereotypes, definitions, and constraints. Lastly for Structure diagrams are Composite Structure diagrams. These are used to show the internal structure of a particular class.

For Behavioral diagrams, we start first with the Use Case diagram, which is used to show an overview of various actors that are involved in a system, how different functions are needed by those actors, and how the different functions interact. Activity diagrams are used to represent workflow, for example business or operational workflow. State Machine diagrams are similar to Activity diagrams, and are used to describe the different behaviors of objects and how they act based on what state they are in. Sequence diagrams show how objects interact with each other and, as the name Sequence implies, what order they interact. Communication diagrams are what the old UML 1 Collaboration diagram was. These are similar to Sequence diagrams, but are focused on the messages based between objects, instead of the order they interact. Interaction Overview diagrams are essentially multiple Sequence diagrams all inside another diagram, to show how many things interact and how they interact with each other, and in the order that they interact. Timing diagrams are also like Sequence diagrams but show the behavior of objects within a specific timeframe. 

I chose the following blog post because it gave clear and concise definitions and explanations of the many types of UML diagrams, and allowed me to appreciate them even more than I did before.

Link

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

Erockwood Post #5

An important part of software testing is the testing of the software itself. But what if you were able to automate the testing? One of every programmers core ideals is to try to automate as much as possible, because programmers are “lazy”. One framework that allows you to do this is Gradle. Gradle is a build automation tool rooted on JVM, so it is perfect to use with Java. We can use GitLab’s Continuous Integration tool to allow our code to run and test every time it is pushed to GitLab. This is very useful so that any changes made are automatically test each and every time an update is pushed to Main. Once you have your Java project set up, you need to initialize Gradle into the directory of the Java project. After you have done that, you can copy your Java files to the Main src folder in the new Gradle section in the directory. All of your test files will go to the Test src folder. You can then run gradle build to build the project, then gradle test to run all of your tests in the test files using the files in the Main folder.

After this and gradle test outputs successfully, you can set up GitLab’s Integration by using the .gitlab-ci.yml file in your project. After you have added that, all you need to do is use Git to commit and push your project to GitLab and then check the CI/CD tab to watch your tests run.

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

Erockwood Post #4

When testing software, it can be useful to have testing objects in place to help test methods and functions to ensure correct output, but without having a real object. This is where the multiple types of test doubles come into play. There are four types of doubles, dummies, fakes, stubs, and mocks. Dummies are objects that are passed around, however never actually used. They are commonly used to fill parameter lists and the like. A fake is an object that actually works, unlike a dummy, however there is usually some kind shortcut taken that does not make them suitable for final production. A stub is used to get a certain answer from a test, and they will not respond to any outside input, only what they are programmed to do. And lastly, we have mocks, which are objects pre-programmed to respond to certain expectations given the input of the calls they receive.

These objects are all very useful when it comes to testing, as they can all help save time when only certain aspects of a program need to be tested, without having to use the full functionality of a particular object. Dummies are nice in that they can help with filling lists and arrays. Fakes are also nice because they allow you to have a part of an object without having to use the full object itself if you want to test only a part of an object. Lastly with mocks, we can use them to get predetermined outputs for certain inputs, which would assist with testing.

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

Erockwood Post #1

In my operating systems class, we are learning about all of the important roles the operating system has in a computer. There are many managers that the operating system itself manages to keep everything running as smoothly as possible. One thing I am most interested in when thinking about operating systems is concurrency and multithreading. Most tasks are done serially, which is to say one at a time. This worked well back in the day when most computers had only one or two cores. Nowadays, however, CPUs usually have 4+ cores, and if all tasks an operating system does are serial, then 3/4 of the CPUs resources are not being utilized. This is where concurrency / parallelism / multithreading comes into play. With them, we allow programs/tasks to run simultaneously, using more than one CPU core, to do more work in less time.

The only problem with this is trying to write the programs/tasks to take advantage of more cores. I know when I first tried to create and run a simple C program that would use more than one core, it was very confusing on trying to have everything be worked on by a separate thread. Eventually, after some trial and error, I got it working, and it slowly started to make sense on how to write this type of program. In doing some very simple calculations like I was trying to do in my example program, there is not much performance to be gained from multithreading the program, but in much bigger programs with bigger calculations to be done, there is definitely some time that can be saved by multithreading the process.

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

Erockwood Post #3

Today we will be discussing some things I find interesting in one of my classes. In this class, we are learning about cloud, parallel, and distributed computing. I find it very interesting that we are able to use one fast computer to send tasks to a bunch of slower computers to calculate data in a very quick and efficient manner, rather than just running the data through one singular computer. I also find it interesting how systems like Hadoop are able to maintain data integrity by storing all information in three different places so that if a computer dies, it still has the data in two other places, in which it will then get the data to another computer to keep the data in three places going.

We are currently discussing machine learning, which I personally think is a little overrated. All it really is is just telling a computer when it guesses if it is right or wrong then it adjusts its guesses accordingly until it gets about 99% correct. This is called training. Once the computer is “trained” it is good to go. Statistics and machine learning go hand in hand, as both are used to take data and use that data to predict outcomes based on the input data. One subset of machine learning is data mining, which is many different methods used to extract insights from data.

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