Category Archives: Week-15

REST – Representational State Transfer

REST is a term coined by Roy Fielding to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.  It represents the state of database at a time. REST is an architectural style which is based on web-standards and the HTTP protocol. In a REST based architecture everything is a Resource. A resource is accessed via a common interface based on the HTTP standard methods. You typically have a REST server which provides access to the resources and a REST client which accesses and modifies the REST resources.  Every resource should support the HTTP common operations. Resources are identified by global IDs. REST allows that resources have different representations, e.g., text, XML, JSON etc.

HTTP Methods

The PUT, GET, POST and DELETE methods are typically used in REST based architectures. The following table gives an explanation of these operations:

POST –> INSERT (adds to an existing resource)

PUT –> UPDATE (overrides existing resource)

GET –> SELECT (fetches a resource, while the resource is never changed via a GET request)

DELETE –> DELETE (deletes a resource)

 

USE NOUNS BUT NO VERBS IN PATH/URI:

Purpose Method Incorrect Correct
Retrieves a list of users GET /getAllCars /users
Create a new user POST /createUser /users
Delete a user DELETE /deleteUser /users/1
Get balance of user GET /getUserBalance /users/1/balance

USE PLURAL NOUNS

Do not mix up singular and plural nouns. Keep it simple and use only plural nouns for all resources.

/cars instead of /car

/users instead of /user

/products instead of /product

 

SOME TIPS FOR YOU:

  • Use PUT, POST and DELETE methods instead of the GET method to alter the state. Do not use GET method or Query parameters for state changes.
  • If a resource is related to another resource use sub resources.
  • Both, client and server need to know which format is used for the communication. The format has to be specified in the HTTP-Header.
  • Make the API Version mandatory and do not release an un versioned API.
  • Use a simple ordinal number and avoid dot notation such as 2.5
  • Use a unique query parameter for all fields or a query language for filtering.
  • Allow ascending and descending sorting over multiple fields.
  • Use limit and offset. It is flexible for the user and common in leading databases.
  • To make the API experience more pleasant for the average consumer, consider packaging up sets of conditions into easily accessible RESTful paths.

 

References:

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

https://restfulapi.net/

https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/

Thank you for your time!

 

 

 

 

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

SOAP vs. REST

SOAP and REST both allow you to create your own API. API stands for Application Programming Interface. It makes it possible to transfer data from an application to other applications. An API receives requests and sends back responses through internet protocols such as HTTP, SMTP, and others. Many popular websites provide public APIs for their … Continue reading SOAP vs. REST →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Behavior-Driven Development

Hello dear reader. Welcome back to my blog. We talked in the previous blog about Test Driven Deployment. Now it is time to talk about Behavior Driven Deployment. Behavior Driven Deployment is a software development methodology that combines practices from test-driven development and domain-driven design. As we mentioned in the last blog test-driven deployment focuses development on short, cyclical iterations in which (failing) tests are initially created that define the wanted functionality, and only then is actual code written that ensures those previously-failing tests can now pass. Domain-driven design in the other hand, centers on the concept of domain and domain logic. Thus, DDD practices attempt to simplify the terminology in the project scope by focusing and defining everything in the application as real-world objects or concepts that most people are familiar with.
By the combination of TDD and DDD, Behavior Driven Development aims to simplify development trough the use of a common domain-specific language.
As behavior driven development is derived from influenced by TDD, many of the same benefits apply to BDD as well. BDD it reduces regression. When you have a full suite of tests being continually executed, and with new tests always being added, BDD reduces extremely the likelihood of regression bugs popping up as the code is in constant monitoring and testing.
BDD also improves team communication. Since there is a common real-life basis for phrases and terminology when discussing a project, BDD can often improve communication across the entirety of the team.

BDD has also disadvantages like it requires specifications before development and relies on constant outside feedback.

Personally, I like TDD testing better as the code does what you are testing and believe me when I say that the documentation and specifications are bad for a project. There are usually lots of misunderstanding in the specification of a project. It also depends on the project and the company. Thanks for being my reader again.

https://docs.cucumber.io/bdd/overview/

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

Common Software Testing Techniques

Good day, again dear reader! With classes wrapping up this week and finals starting, I was a little curious at what other testing techniques there were for testing that were not discussed in class. Of course, this lead me to an article called, “The 7 Common Types of Software Testing“. This article had a mix of things discussed in class and some new ones as well.

The first type of test was a black box test, something we discussed in class. In fact, it was among the first we discussed. For a brief review, black box testing is when we are solely concerned with inputs and outputs and we don’t know anything about how the code works or calculates the actual results.

The second test mentioned is white box testing. Another testing method discussed in class. If I remember correctly, it was discussed on the same day as black box testing. Here in white box testing, we can see inside and get a feel for how the program actually works and calculates outputs.

Acceptance testing is a new one to me. Acceptance testing is two-fold. It tests both the system as a whole and it tests the actual requirements of the customer. This test is geared more towards user-friendliness and usability that some of the other tests.

Automated testing is simply any test that has been automated. This I think is more part of other test techniques and not its own technique.

Regression testing is testing the system to ensure that it works the same way as the previous system. This is done in incremental development to ensure that as new parts are added, the original system isn’t broke.

Functional testing is the testing of the system to see if it is functional. The author points out that there is more than just functionality to test for a program and uses that to justify functional testing as its own technique. I’m not quite sure about this decision but I can stomach it for now.

Exploratory testing is testing a system without any actual test cases and exploring the system looking for things that might be wrong or unexpected. Reading the description, it appears to be for testing systems in unusual ways that might not be conventional and testing the boundaries of a system, possibly uncovering bugs that normal testing methods might not find.

Of these new test methods, none of them have really captivated me. Exploratory testing, being honest, sounds a little silly and I can’t really see too many benefits to it. Out of all seven I quite like acceptance testing as it seems to keep the focus shifted to the customer and not just to it the system works or not.

Until next time readers!

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

Adapt or Git Left Behind?

CS SERIES (15)As my last fall semester comes to a close, I wanted to write about an article on something pretty interesting I learned about in my software construction and design course.

On Stackify, Thorben Janssen wrote Design Patterns Explained–Adapter Pattern (with code examples). Overall, this article re-instilled how design patterns make it easier to write more well-structured and maintainable code.

I found it useful to see how Janssen discussed the two different versions of the class adapter; the class adapter pattern (which implements the adapter using inheritance) and the object adapter pattern (which uses composition to reference an instance of the wrapped class within it).

Similar to how we learned the concept in class, something I appreciated is the “real-life” example or comparison used to describe the physical adapters we use when traveling. When we are traveling and do not have compatible power sockets, we must find a way to be able to charge our use our devices without having to change the whole make of it. A way of doing so is by using adapters; which does not change the overall product or device, it just allows you to be able to plug it in.

An situational example that I can think of when explaining adapters is if you have ever been zip-lining or done a ropes course (like Go Ape) where you are attached to a harness. When you are transferring from one line to another, you can use a metal contraption which helps guide you while connecting and disconnecting from paths. That metal contraption serves as an adapter, not changing what you are but allowing you to use something.

I agree with what message Janssen is trying to express about how great design patterns are (the adapter pattern specifically) when it comes to writing code. His content allowed me to think about real life situations in code form when he introduced the basic and premium coffee machines to brew coffee using the adapter pattern. One of the best ways of learning concepts, in my opinion, is to compare it to a real-life situation and then show people visualizations to help them better understand what you are trying to explain and the article did both.

Article: https://stackify.com/design-patterns-explained-adapter-pattern-with-code-examples/

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

I’m Sorry, an Anti what now?

Good day once again my fellow readers! In my readings this week, I discovered something that I had never heard of before, antipatterns. Now that is quite a striking name and it piqued my interest in this subject. So today I will be talking about software development antipatterns, particularly the Blob.

First, let’s discuss what an antipattern even is. An antipattern is simply just an industry term for a common solution to a problem that generates negative consequences. what antipatterns can do for us is twofold. First, they provide a template to help us recognize common problems that can crop up in software development. With this knowledge, we can recognize an antipattern when we see one and identify the cause of it as well. The second part is that antipatterns provide a constructive solution to fix the underlying cause of the antipattern and to implement solutions that can be applied at several different layers in design. Let’s look at the first antipattern I discovered, the Blob.

The Blob is much like its namesake of horror film fame, the Blob. Here one single complex controller class is surrounded by many smaller data classes that merely encapsulate data. In this architecture process is separated from data, thus making this procedural style architecture. Some typical causes of the Blob are lack of object-oriented architecture or lack of any architecture whatsoever. A common occurrence of the Blob is from iterative development where code evolves from proof of concept to a prototype to a functional system. Another cause is a lack of architecture enforcement. But how can we fix this Blob problem?

Refactoring to the rescue! The first step is to locate sets of operations and attributes that directly relate to each other under a common goal. The next step is to locate natural homes from these groups and migrate them to their new homes. We then remove all redundant, indirect associations and migrate associates to derived classes to a common base class. Lastly, remove all transient associations, replacing them if appropriate with type specifiers to attributes and operations arguments.

This discovery of antipatterns for me was quite the find. I don’t know what but I still get a strange feeling when I hear antipatterns. It just sounds so menacing. The Blob was an interesting first antipattern to read as I’m positive that over my past coding projects, many of them would probably fall into this antipattern. It is nice to be aware of these potential issues now, rather than further down my career where it could have a greater impact if I ever do fall into the trap of an antipattern. I definitely plan to read more about these antipatterns and I plan to write about another one next week.

Until next time readers!

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

REST APIs – A Few Good Guidelines

Today I will be looking at an article that examines five basic guidelines when creating a REST API program. I thought that after spending over a month on our final project creating a REST API backend it would be good to review some good practices for creating these REST APIs. The article gives five basic guidelines to follow and a brief background on each of the guidelines. The five guidelines are: name and case conventions for URIs, the different HTTP methods, HTTP headers, query parameters, and status codes. Some of these topics were a refresher from what we’ve already been taught, such as some of the HTTP status codes, and others were new such as the query parameters or case conventions. I especially thought the name and case conventions for the URIs was interesting. I don’t think I have reviewed naming conventions in coding in a couple of years, I usually use camel case for everything since I mostly write in Java. But I have been wondering what was the best practice for endpoints since I remembered code with HTML being more case sensitive. Also, with using different naming schemes instead of just using verbs that describe the method as in Java. I will keep in mind going forward to use the spinal-case method when creating endpoints. The HTTP methods section was fairly straightforward with what I already know, and the use cases for most of them are the same, but it does have a couple of additional methods I haven’t seen before such as HEAD or OPTIONS. The HTTP headers section was interesting, giving definitions and names for the different types of headers you use for different requests. The query parameters section was the most interesting and something that I haven’t come across yet working with REST. The status codes were familiar too, I have mostly used OK, CREATED, and NOT FOUND in my endpoints. Although I will start using NO CONTENT when performing a deletion endpoint instead of just 200-OK, as this seems to be the more proper response code. The same with using a 400 error of BAD REQUEST instead of just giving everything a 404-NOT FOUND error when an invalid request is made or an item is not available. In the future when working with REST I will keep in mind these simple guidelines from this article, especially in regards to case conventions for endpoints and with using appropriate status messages.

Source: https://dzone.com/articles/5-basic-rest-api-design-guidelines

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

Keeping Up with the Software Developers

To kick off this week of blogging, the first article of the two I will be writing about this week is titled, “How To Keep Up To Date As A Software Developer”. Like all of the other articles that I have written about on this blog, I just happened to spot this article as I was searching for other articles to write about. Although, this one stood out to me because I recently had an interview for a software development internship near my hometown, and it got me thinking. Maybe I should actually stay up to date in the latest software development trends. Luckily, I happened to stumble upon this piece of coincidental, appropriate-to-my-situation, of writing. So without further adieu, let’s talk about the read of this week.

This article is actually written in the form of an interview. The article leads off with the question, “How do you keep up to date as a web/software developer?”. This was a question that was asked on Quora, which is kind of like Yahoo! Answers, but more credible… I think. Regardless, however, the person who answered this happened to be Mario Peshev, CEO of DevriX. DevriX, if you didn’t know, is a company that handles creating WordPress platforms for other companies. I also didn’t know that, but thankfully the internet exists. I still think the article could have explained that, but what do I know about writing articles. Anyway, Mario goes on to talk about what he does to “keep up to date”. Honestly, it was exactly what I expected it to be, which is disappointing, but I don’t know what I expected. He provides 12 ways to keep up to date, and they are exactly what’d you’d expect. (Collegues, Internet, Working, Social Media, etc.) He did mention books which is an obvious answer, but he mention the Gang of Four book, and that immediately caught my attention. It made me feel all professional because we used that book in class, so, in the end, Mario and I are basically the same, except he makes a lot more money than I do.

This article would have to rank low on the list of articles I read because it was predictable. I’m not saying that the article was bad, but obviously, books and the internet are good ways to keep up to date. Granted, I don’t know why I expected there to be some magical new way to keep up to date that only Mario knew, so I guess that is my fault. Overall, this was a good read, but you already know how to do this, so you are better off finding another article.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Mutation Testing

For today’s blog post I wanted to cover mutation testing. I felt that this was a topic that we went over in class but felt like I may have missed something due to the short window of time that we had to review the topic. I found an article on guru99, a site that is becoming a go-to site for me, that is specifically about mutation testing. The article has several sections including a general overview of what mutation testing is, different types of mutation testing, and the advantages and disadvantages of mutation testing.

The article states that mutation testing “is a type of white box testing which is mainly used for unit testing.” White box testing implies that the code is inherently visible and known to the tester, or the person writing the mutation tests in this particular case.  The article states that the goal of mutation testing is to “assess the quality of the unit tests which should be robust enough to fail mutant code.” This opens up the conversation of what is this mutant code you speak of? The mutant code is a slight altercation to the original, and intended code such as changing a conditional > to a <. One of the most important aspects to note is that when performing mutation testing, only one altercation should exist for each test case. In the example I gave where you could change a > to a <, this would be the only change that would be made in the entire code that is being tested.

The article states that mutation testing is useful (the advantages) because “It is a powerful approach to attain high coverage of the source program,“ and it has the “capability to detect all the faults in the program.” Mutation testing finds any instances where a test should be failing but it is not. One of the biggest faults of mutation testing is that is nearly impossible to maintain without an automation tool, as stated in the article. The number of possible mutations to attain full coverage is not realistic to attain without automation.

I could see myself using mutation testing in the future as a means of attaining full coverage for testing. It is definitely a powerful means of testing if it can feasibly be implemented.

 

Link to original article: https://www.guru99.com/mutation-testing.html

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Graph Theory

Summary

In the article A Gentle Introduction To Graph Theory, Vaidehi Joshi goes over some of the basic concepts in graph theory, such as the difference between trees and graphs, undirected graphs vs. directed graphs, vertices and edges, and unordered vs. ordered pairs in graphs. She also provides great illustrations for the differences between each of these topics.

Later in the article, there are great real-world examples of what graphs are used for. For example, she talks about how two different social networks, Facebook and Twitter, are each different types of graphs. In this case, Facebook is an undirected graph because a connection on Facebook has to be a bidirectional connection. Twitter, on the other hand, is an example of a directed graph, because you’re able to “follow” someone without them following you back, meaning it can be unidirectional. The other example that she used that I found useful was comparing the web (traversing between web pages) to one big graph. So as you navigate back and forth between different URLs, you’re just navigating throughout one massive graph. For example, each article on Wikipedia contains key words that link to other articles, which could even potentially lead back to the original article.

Reaction to Content

I chose this topic because I wanted to get a quick refresher on it. While I’ve been exposed to this type of data structure before and seen some of the algorithms used for traversing through graphs, I haven’t really used them outside of coursework. Also, I feel as though I didn’t really have a great understanding of this topic until now. Seeing the examples provided in the article of real world applications of graphs I think was very useful for me to understand their purpose.

Overall, I think this article in particular is a great introduction to graphs, going over basic types of graphs and the concepts needed to understand them. While I already had a decent understanding of graphs, it was useful to reread some of the concepts and reinforce my understanding of them. However, there are many more topics that are important to grasp in order to understand graphs fully, such as the different types of traversal algorithms used for graphs as well as other different types of graphs like weighted graphs or trees.

 

Source: https://medium.com/basecs/a-gentle-introduction-to-graph-theory-77969829ead8

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.