For the past few weeks, I have been working on class activities relating to REST API Design. I wanted to research more about it before continuing to homework assignments utilizing it.

This led me to the website: https://www.mulesoft.com/resources/api/what-is-rest-api-design.

REST API is an application programming interface that uses the constraints of REST, or Representational State Transfer. REST API takes advantafge of HTTP which means that developers do not need to install additional software to utilize it. There are six main constraints of REST API design: client-server, stateless, cache, uniform interface, layered system, and Code on Demand.

Client-server constraint: the client and the server should be separate from each other and be able to change separately. This would allow changes to be made to a mobile application without impacting the server, and also for changes to be made to the database or server without affecting the mobile application.

Stateless constraint: REST APIs are stateless, meaning that each call can be made independently and have enough data to complete itself. REST APIs should only rely on the data that is given in the call itself. Servers do not store identifying information; instead the call has that information, be it an access token or user ID. This helps make the API more reliable because it does not need to rely on multiple calls to the server to create an object.

Cache constraint: REST API should encourage cacheable data to be stored.

Uniform interface constraint: the uniform interface should provide a standard way to communicate between the client and server. The uniform interface should also allow the evolution of the application without the application intertwined too much with the API layer.

Layered system constraint: having a layered system helps shield differently accessed components from one another. It allows for systems to be moved in and out of the architecture which can help as technology evolves. It can also help with security, as it can help with attacks at a proxy layer or other layers before it reaches actual server architecture.

Code on Demand constraint: this constraint is optional, but it allows for code or applet to be sent out through the API, meaning the server can add information to the code.

I chose this source because I wanted to read about how REST APIs are broken down, and how these constraints are helpful. This source helped me understand how the individual evolution of the servers and the clients are important, and I will consider this information for when I need to decide if REST API is the type of API I should utilize for a future project.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to another week of my blog! This week I want to talk about SOLID design principles since it is important for other programmers to read and understand your code so you can collaboratively work together on it. Having code that is not clean and hard to understand will ultimately hinder you in the long term. Having clean code also makes your code easier to write and understand as well. The term SOLID stands for multiple things: The Single Responsibility Principle, The Open-Closed Principle, The Liskov Substitution Principle, The Interface Segregation Principle, and The Dependency Inversion Principle. These principles were made by a Computer Scientist named Robert J. Martin who is also the author of Clean Code. I’m reading that book for CS-348. Starting with the Single Responsibility Principle, this principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change. For example, there is a program that calculates the area of shapes. There would be classes that define the shapes themselves (ex. Class Square) and a class that calculates the area of the shapes (ex. Class ShapeArea). The ShapeArea class should only calculate the area of the shapes. The open closed principle means that classes should be open for extension and closed to modification. This means that programmers should be able to add new features to the code without touching the existing code because touching the existing code could create new bugs. The Liskov substitution Principle states that subclasses should be substitutable for their base classes. This means that if class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case. The interface segregation principle states that larger interfaces should be split into smaller ones. By doing that, we can ensure that implementing classes only need to be concerned about the methods that are of interest to them. The last one is the Dependency Inversion principle. The general idea of the principle is that high level and complex modules should be easily reusable and unaffected by changes in low level utility modules. To do this, there needs to be an abstraction between the high level and low level modules so they are separated and you can tell them apart. Those are all the SOLID principles. Thank you for reading this blog post!

https://www.bmc.com/blogs/solid-design-principles/#

From the blog Comfy Blogging by and used with permission of the author. All other rights reserved by the author.

One of the more interesting topics that we covered in class was semantic versioning. I found it interesting because it is something that I see all the time but had no idea what it meant. After reading over the documentation, I’ve learned that semantic versioning is a set of rules that dictate how version numbers are assigned and incremented. Semantic versioning was proposed as a solution to dependency hell, which occurs when you version lock or when version promiscuity prevents you from easily and safely moving your project forward.

Semantic versioning works in three parts, X, Y, and Z. They are usually written as X.Y.Z, as that is the form semantic versioning must take. Each component says a different thing about the version. The X states what the current major release is, the Y states what the current minor release is after the last major release, and the Z states what the current patch release is after the last minor release. What do a major release, minor release, and patch release mean?

A major release is the first part of the semantic versioning framework. It goes at beginning of the version number. A major release occurs when you make incompatible API changes. The changes must be backward incompatible in order to be considered major. A major version zero is for initial development, and anything may change at any time. When a new major update is released, the minor, and patch version numbers must be reset back to zero.

A minor release is the second part of the semantic versioning framework. It goes in the middle of version number.  A minor release occurs when you add functionality in a backward compatible manner. A minor release needs to be incremented every time any public API functionality is marked as deprecated. Minor releases could also be incremented if substantial new functionality or improvements are introduced within the private code, and it could include patch level changes. When a minor update is released, the patch version number must be reset to zero.

A patch release is the third and final part of the semantic versioning framework. It goes at the end of the version number, and it refers to an update that focuses either exclusively or primarily on bug fixes. A bug fix is a change made to the code to correct incorrect behavior. A patch release does not add any new features, it just modifies existing code to fix errors or make the code run the way it was intended. All the bug fixes must be backward compatible.

https://semver.org/

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.

This week I read a blog post about eight ways to make software development go by faster, and I thought it was an interesting read to share with everyone. The blog starts off describing time as the most valuable resource in the software world, and how faster is better. The blog then goes into the different options of speed such as marathons, extreme sprints, moderate sprints, and intervals. You can select between the four for whichever project you are doing. The eight ways are shown as skills, experience, system complexity, technical debt, refactoring, slow automatic tests, overtime/deadlines, and passion. It concludes by describing software development speed as complex, and that it has no easy solution, but it does have a lot of different solutions depending on how you work. I selected this blog post because this class is a software development focused class, and I see my future in that area, so I want to know the most about it.I think this blog was a great read that I recommend for many reasons. A huge reason I selected this blog is because I want to become a software developer myself in the future, so it was a read that I could enjoy. It is good to read the blogs on things you care about because it makes the recommendation much more credible. Another reason I selected this blog was because it does a good job of showing the most important part of a software developer job. How to make more out of less time. It gives a huge number of different ways to solve the problem, and they all are viable answers. The last reason I will be going over is that it does a good job of tempering expectations. Time management is an important resource when it comes to software development, but it is not just some beginner’s problem. Experts still struggle with it occasionally today, so do not expect it to be an easy problem to answer. I learned about how important speed is to software development, and how many factors contribute to it, and how complex it is.This material affected me hugely because it showed how important conserving speed to save money is, and how I can use certain methods in the future to make projects go faster. I will take all of this knowledge with me as I continue in my career. Everyone who wants a career in software development needs to read this because it shows how time literally is money.

link : https://www.apptio.com/blog/speed-in-software-development/

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

A while ago, I introduced the concept of API in the information technology industry. In addition, there are 3 different types of Web Services APIs which are REST APIs, SOAP APIs, and RPC APIs. Among them, REST APIs is no doubt the most popular API currently. REST APIs, also known as RESTful APIs, stands for Representational State Transfer. It is based on four different HTTP commands which are GET, PUT, POST, and DELETE.

When a client request is made via a RESTful API, it transfers a representation of the state of the resource to the endpoint. Then the information is delivered in one of several formats via HTTP: JSON (Javascript Object Notation), HTML, XLT, Python, PHP, or plain text. JSON is the most generally popular due to its readability.

According to the RESTful API website, a service interface needs to apply these 6 guiding principles and constraints to be referred to as RESTful:

1. Uniform Interface

Multiple architectural constraints applying to the interface so that information is transferred in a standard form requiring:

Identification resources – resources requested are identifiable and unique from the representations sent to the client

Manipulation of resources through representations – clients can manipulate the resources via the representation

Self-descriptive messages – each resource representation should carry enough information that the client can manipulate.

Hypermedia as the engine of application state – after accessing a resource, the client should be able to use hyperlinks to find all other currently available actions.

2. Client – server

It is the architecture made up of clients, servers, and resources, with requests managed through HTTP.

3. Stateless

Statelessness means that no client information is stored between each request and that the server cannot take advantage of previously stored context information.

4. Cacheable

There are cacheable and non-cacheable responses. If the response is cacheable, the client can reuse the response data for later use.

5. Layered system

A layered system allows an architecture to be composed of hierarchical layers by constraining component behavior.

6. Code on demand (optional)

It is the ability to send executable code from the server to the client when requested, extending client functionality.

Although REST API has these criteria to conform to, it is still considered easier to use than SOAP (Simple Object Access Protocol). The reason is that while REST is a set of guidelines which is simple to implement and faster in response time, SOAP has specific requirements like XML messaging, and built-in security and transaction compliance that make it slower and heavier.

Overall, the point of this blog is to introduce you to REST API, REST is just a term indicating the constraints applying to the API. In order to understand the power of REST, I would suggest going to create one and see how simple and convenient it is.

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

Hello, week-9. I want to post a blog to quickly review the API topic to learn more about REST calls. I got confused; I researched about it. It has the Understanding And Using REST APIs.

What is a REST API

API (Application Programming Interface) – A set of rules allows programs to support any other. The developer creates the API on the server and enables the client to speak to it. 

The REST (Representational State Transfer) determines how the API. It is a set of rules that developers follow when they create their API. One of the rules states that one should get data (called a resource) when linking to a specific URL. Each URL made a request, while the data sent back to is called a response.

The Anatomy Of A Request #

It’s important to know that a request with four points:

• The endpoint
• The method
• The headers
• The data (or body)
  

The endpoint – URL that requests for (root-endpoint/?). The root-endpoint is the starting point of the API that is ordering.

The path determines the resource request. For example, it is like an automatic answering machine. That asks to press 1 for service, press 2 for another service, 3 for yet another service, and so on.

The Method

The method is the type of request sent to the server:

• GET – Request to get a resource from a server. It will perform a `GET` request; the server looks for the requested data and sends it back.
• POST – Request to create a new resource on a server. It performs a `POST` request, the server creates a new entry in the database and tells whether the creation is successful.
• PUT & PATCH – Requests to update a resource on a server. If performing a `PUT` or `PATCH` request, the server updates an entry in the database and tells whether the update is successful.
• DELETE – Request to delete a resource from a server. If performing a `DELETE` request, the server deletes an entry in the database and tells whether the deletion is successful.

These methods provide meaning for the request made. Perform steps: Create, Read, Update and Delete (CRUD).

The HEAD: it used to provide information to both the client and server. It has many purposes, such as authentication and giving information about the body content. It can find a list of valid headers on MDN’s HTTP Headers Reference.

The Data – contains information sent to the server. It only used POST, PUT, PATCH, or DELETE requests.

From the blog Andrew Lam’s little blog by and used with permission of the author. All other rights reserved by the author.

This week I researched more about docker to know what it exactly is and what are the applications of it. I had never heard or used docker before I joined this class and since we use docker for almost every class I was just curious to learn more about it and from the things learned during the class, it looks like docker is one of the useful software and very versatile in the field of software development.

Docker is a set of platforms as a service product that uses OS-level virtualization that delivers different software in packages and they are called containers or Docker can also be referred to as an open-source platform for building, deploying, and managing containerized applications. Since docker is open-source, it enables developers to package their application into containers, these containers simplify the delivery of distributed applications and has become popular as different organizations shift to could-native development and hybrid multi-cloud environments. A docker file contains simple textile that starts with every docker container and contains instructions for how to build a Docker container image, that file automates the process of Docker image creation. Docker image contains executable application source code as well as all the necessary libraries, tools the application code needs to run the container properly. Docker images are made up of layers, and each of those layers corresponds to the version of the image. Docker containers are the live, runner instances of the Docker images and this helps users to interact with them, thus one can adjust their setting according to their preferences. Docker hub is a public repository where Docker images are stored and can be used by all Docker Hub users. The advantages of using Docker are they are cost-effective with fast Deployment, Able to run anywhere, Flexibility, and so on, the disadvantages are its advances quickly thus but lack documentation that makes some developers hunt for information which then wastes time for those developers, some developers find switching to docker is a quite a steep learning curve thus making it hard to understand for some people.

I choose this article because it explains Docker and its tools in the simplest way which helped me understand more about docker since it’s the first time I have ever used this application. It explains the advantages of using docker and this article provided clear information on different aspects of docker such as Docker File, Docker images, Docker containers. And since its one of the most used application throughout the software developers it will be important for me too in the future as a software developer.

Article: https://www.ibm.com/cloud/learn/docker

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

Christian Shadis

For the past couple weeks, my Software Construction, Architecture, and Design course has been focusing on the anatomy of simple REST APIs. While we were learning about how to create endpoints to retrieve data from the backend, it was as simple as just extracting the data from the database on the backend. This seemed too basic to me. Though I was sure there was still plenty of unexplored detail in the backend regarding security protocols, I was curious to see how security measures can be implemented in a REST API like the ones we have been working with.

Chris Wood discussed Security Scheme Objects and their role in the REST API, listing supported security mechanisms (Basic Authentication, API Key, JWT Bearer, and OAuth2.0), in his 2019 article REST API Security Design. He began by defining what a REST API Security Scheme Object is: a Component object (like Schemas or Responses) which “[describes] the security requirements for a given operation.” There is not a specific object for each of the mechanisms listed above, but rather a single Security Scheme Object that can represent any of the four mechanisms. The Object is defined in the top-level index.yaml file under the Components section, the desired mechanism is applied, and any additional arguments specific to the mechanism are passed. Once it is defined, the Security Scheme Object can be applied to individual endpoints or operations. For example, for some path /users/, we define an operation get, and underneath the parameters and responses section, a security section can be added containing an array of Security Scheme Objects to be applied. If we define a BasicAuth object and assign it to the get /users/ endpoint, other developers know that the operation should have basic authentication.

My main takeaway from the article was that my perception of API security was flawed. Whereas I had considered the idea of implementing security measures directly into the API itself, the article outlines instead that security measures in an API consist primarily as a guide or a definition of security requirements for other developers to uphold. For example, authentication itself is not performed inside our REST API by implementing one of these Security Scheme Objects. Rather, the API designer can specify that some specified authentication should be included in certain operations by defining them in the API.

While security measures in API design may not be as essential as I believed, the article asserts that it is a vital factor of API design. As I continue my career as a developer, I plan to develop all my applications in the most secure way possible. Since API design is such a fundamental aspect of web application development, I am glad to have gained some exposure to how security measures are implemented.

Reference: https://blog.stoplight.io/rest-api-security

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Let me just begin by saying I really like how this blog post was organized and written. It starts off very formally by giving definitions for the terminology that they would use throughout the post and then transitions to explain those same terms in layman terms. With the way the post is written, the author makes it so even a person without a Computer Science background can semi follow what is going on in the post because the author explains the concepts using things that everyone sees and uses on a day-by-day basis.

The post starts with an example of a web URL and how the statement after the web extension is actually a query string. Then the article goes on to talk about how you can format your search to look for a specific pattern, and max or minimum string length. After going over the basics of how to format query strings, they go to talk about how you can combine multiple criteria to further down your search.

For example:

Somedictonary.com/words/?letter=5&partOfSpeech=noun

This finds you all of the five-letter nouns in the dictionary.

The reason why I chose this particular blog post to read and talk about this week is because it is relevant to what we are learning in class. It is a topic we are going to go over in class and have already talked a little bit about this topic in class. In addition, we are using also using it this week for the homework. I chose this post because I think it does a great job explaining the topic. The post is short and worded in a way that I think is easy to understand. It also uses a lot of images and examples, so it was also easy to follow along with what the author was saying about the topic.

In class when we started talking about this topic, I did not think it was particularly difficult to understand, but another reason I chose this blog post is that I have always been the kind of person where I either “use or lose it”. I have always been the kind of person where whenever I learn something new, I need to apply that information or forget about it.

In class, I immediately made the connection that you can use query strings to refine searches in databases but after reading this blog post, I learned you can also apply it to websites. In a way, I think I have always known this because often times when I am navigating a website and want to go from one page to the next, I may just change the page number or page entry in the URL. I don’t think I would have put two and two together and realized on my own that what I was doing was modifying the query string or that I was switching from one endpoint to another.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.