I have been learning more about REST API. Currently I have been working on backend implementation. Working on this is somewhat difficult. I understand how to implement new endpoints to get certain objects, but I have trouble in other things. It mostly has to do with the current homework.

So, I decided to learn more about it. I went to a blog from Stack Overflow since it is well known for having useful information about coding. If you need a question answered or a working piece of code you go there. I have used it before, and it was helpful. Hopefully, by the end I get a better understanding of the material and can utilize that newfound knowledge in the homework.

I used this: Best practices for REST API design – Stack Overflow

The article discusses the best practices for REST API design. It discusses using logical nesting to group associated information, and handling errors gracefully. It also discusses allowing filtering, sorting and paginating data. They are utilized to help deal with large data by only outputting the data that is needed. Let’s say there is 400 pieces of data and you only need 4%. By filtering, you can get that 4% without dealing with a slowdown and having to parse through data to see the 4%. The article also discusses versioning APIs, maintaining good security practices, caching data and minor things like using nouns instead of verbs in endpoints. It also discusses the importance of JSON and how it can be used for transferring data.

There is useful information but the one that stood out to me was the one about filtering, sorting and paginating data. There is a part of my homework that requires filtration. I need to make sure that when guest age is called, depending on the way GET is structured the resulting list is greater than, less than or equivalent to the chosen value. That section in the article gave me an idea. Like the example given in that section, I could use an if statement to filter out results. This may get the result I want.

To conclude, this article has been really useful to me. It has helped me understand what I have to do for a part of my homework assignment. It was interesting to learn ways to improve my REST API design. I may not know if you I will use this information in the future, but I know that I will use it now.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

I have been learning about REST API. There is UUID. It stands for Universally Unique Identifier. It is a combination of numbers that represent a user, keeping them anonymous. REST APIs adhere to the constraints of their RESTful architecture. They contain a base URL, a media type and standard HTTP methods like GET, PUT, PATCH, POST, and DELETE. POST creates new entries in a collection. PATCH updates a certain member in a collection. Think of sewing a patch in a part of a blanket. You can’t sew a patch over a whole blanket. GET retrieves (or gets) information of a collection or specific member. POST creates a new entry like making a post to add to the sea of posts online. PUT can replace a collection, replace a specific member or change an aspect about a member. There are also codes associated with the outputs of these commands. There is 200 which means that a command was executed successfully. There is 201 which means a POST has successfully created an entry. There are unsuccessful requests like 400 which means that the request itself has an error, 500 which means that the server could not do the request and 404 means that it cannot do what is requested. That is the bulk of what I know.

The main reason for the post is to learn more about REST APIs. I am using this website as my source: Debugging APIs Best Practices for Product Managers

This article seems to have more than the basics. Most of the other articles just go over what I know. This article goes over how to debug APIs. Debugging in general is a very important skill for any coding language. In fact, most of the time a developer spends on a project is debugging.

The main thing I learned were the steps to debug API. I am going to connect this with REST APIs since it is the API I am familiar with. Step one is to identify the issue. This can be done using developer tools like Chrome Developer Tools. I believe that this is for more complex work since someone could just review the REST API. The second step is just to check the status error code. The third step is just delving in further depending on the status error code. For example, I get a 400 error. I could ask myself am I misspelled something or if my input is not properly structured. Think about step two as gathering information and step three is looking through it. The last step is experimentation. Essentially, use problem solving skills.

Overall, this article gave me a better understanding of REST APIs. I knew a few of the steps beforehand so it was not completely new. It was nice to learn that there are tools to identify problematic API. I will keep it in mind if I ever need to use it. Maybe, I will use it in a future web application development.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Recently I have been learning about Design Patterns. I was specifically taught Strategic Patterns. It is a pattern that defines a family of algorithms, summarizes them, and then divides them up into understandable sections. In this type of pattern, there will always be at least one context connected to a strategy and a strategy connected to its subsections. This pattern also allows for choices in implementation which makes it perfect to have if your code needs to take any deviations due to a client. It is also good for anything that deals with a family of related algorithms, and anything that wants to avoid subclassing and conditional statements. This is good since conditional statements cause unnecessary nesting and put extra weight on the code and subclassing makes the code difficult to handle in the long run due to making it brittle. With this known, it is understandable why many utilize Strategic Patterns.

Now, I have demonstrated knowledge in strategic patterns but why stop there? There are many other pattern categories worth exploring.

To delve deeper into the topic, I used this website: https://sourcemaking.com/design_patterns

This website explains a few design patterns such as: Behavioral, Structural and Creational. It explains them in a beginner friendly manner, which is the main reason I chose it. It also defines what a Design Pattern is and the cons of using Design Patterns.

The first thing I learned about was Creational Design Patterns. This pattern focuses on class instantiation which allows you to use the blueprints defined by a class to create objects with specific states and behaviors. Let’s say you need to create a class that holds all existing employees. With class instantiation, you need to add is needed information such as name, email, department. Then, all you would need to do would be to give the employee attributes and the code would sort itself making sure that employee information would be sorted into the exact format you desire. In general, Creational Design Patterns specialize in making this a seamless process for your code.

The next thing I learned was Behavioral Design Patterns. It focuses on class objects’ communication. Sometimes one class needs information from another to initiate, terminate or do a specific task. Behavioral Design Patterns is designed for that. It possesses a chain of responsibility and makes sure each link in that chain runs smoothly. The code depends on it since if one class goes wrong, the others would follow.

To conclude, there are many ways to do Design Patterns. Each have their own purpose and specialties. It was interesting to learn about a few of them, and I wonder if I will have to utilize one in the future. Nevertheless, it was interesting to learn about.

From the blog My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.

Lately, I’ve been having trouble with UML Sequence Diagrams. So, I decided to do further research to better understand the subject.

Due to learning about it in class, I have some prior knowledge about the subject. First, there’s the actor which is usually represented by a stick figure. The actor essentially acts as a user stand in. The rest of the classes are participants. Think of them as a path the actor has to walk across. The diagram shows the path that the code takes when the user executes the code.

I used this article for reference: Sequence Diagrams – Unified Modeling Language (UML) – GeeksforGeeks

It’s a beginner’s guide to UML sequence diagrams. It defines an UML sequence diagram and all vocabulary associated with it. It then informs how to one and the pros and cons of using one.

The first thing I started to better grasp was lifelines. I used to think lifelines were the solid lines but they depict an individual participant. Lifelines represent each instance in a sequence diagram. They are displayed in rectangles and go by their name and type. They are similar to actors but portrays objects internal to the system.

I also learned more about the messages. I knew that solid lines output messages and dashed lines returned them. I didn’t know that a solid line and a dotted represent synchronous messages and a single dotted line represent asynchronous ones. Synchronous messages wait for a reply before the interaction can move forward. Imagine if to people were moving boxes to a truck. Person A hands a box to Person B who puts it the truck. Person A must wait until Person B signals that they are done with their task. On the other hand, asynchronous messages don’t need to wait for a reply so Person A would just hand Person B the box without waiting for a signal.

So, to summarize what I learned. the diagrams are just a different way to demonstrate the code. It’s a communication tool between developers, managers, stakeholders, project managers and clients. It’s like a blueprint that anyone can look over. Clients can look over the plans without getting confused and make edits if necessary. Developers can take the blueprint and convert it into actual code. UML diagrams contain an actor that takes the role of a user engaging with the code. The participants represent the rest of the classes. The vertical rectangles represent the duration of a class’s execution. The arrows, not participants as previously mentioned, represent the path the code takes. Think about everything as components of a map.

Overall, this further research deepened my understanding of UML sequence diagrams. I feel like this would help me with the homework assignment but unfortunately it didn’t answer all my questions.

From the blog CS@Worcester – My Journey through Comp Sci by Joanna Presume and used with permission of the author. All other rights reserved by the author.