Week 8 Ready For Review

[ArchILLtect]

@pawaitemadisoncollege week 8 is complete

Scope per rubric / plan

• Consume a RESTful web service in your individual project.
• Create a pojo that represents the response from the service.
• Create a client that calls the service and maps the response to the pojo. The client should be created in it's own DAO class.
• Write a unit test to verify the client Dao and pojo work.

Evidence (links, screenshots)

/docs/screenshots/Week8-RestfulAPI_Tests_Passing-QuoteServiceTest.png:

Reflection

Key Learning Points / Takeaways

This week, I deepened my understanding of how to consume and deserialize external REST APIs in Java using HttpClient and Jackson. I learned how JSON structure dictates the POJO mapping (e.g., array vs. object roots) and how to generate and adapt POJOs using RoboPOJOGenerator. I also learned how to design a resilient service layer—adding caching, configuration-based properties, and fallback behavior for failed API calls. Another big takeaway was how to dynamically build URIs with optional parameters (author and tag filters) while keeping the logic clean and flexible for future user-controlled settings.

What Challenged Me

The biggest challenge was troubleshooting SSL/TLS handshake errors when switching from HTTP to HTTPS. This turned out not to be a coding issue but rather a local certificate validation problem caused by an expired or intercepted certificate chain on my machine. Debugging that taught me more about how Java and Windows handle HTTPS validation, truststores, and certificates—definitely outside the usual scope of web app development but valuable knowledge nonetheless.

Problems Solved and Resources Used

I solved several practical problems:

Replaced hard-coded values with configuration properties in application.properties to make the service more maintainable and compliant to class standards.

Implemented a simple caching mechanism and structured log output to improve performance and traceability. I had issues with maxing out calls to the API. I started using Zen quotes and swapped it out for "Quotables API", because they were trying to force me to pay for it.

Identified the root cause of the HTTPS error and implemented a temporary safe fallback to HTTP with a configuration flag and a TODO marker for future TLS remediation.

Resources used:

included the Quotable API documentation, Jackson and HttpClient reference material, IntelliJ’s built-in HTTP client for testing endpoints, and several community discussions/documentation pages on Java’s SSL certificate validation.

Approval checklist

• All checkpoint requirements checked above
• Evidence attached
• Links added (docs, PRs, CI run)
• Ready for review

[pawaitemadisoncollege]

Hi Nick (@ArchILLtect) - wow! There's a lot of complexity here, so lots to review. Your have a good idea with regard to caching and fallback to minimize calls and provide a default in the event that the service is unavailable.

I do have a few questions related to the implementation here:

1. what is the purpose of these properties?

   code-forge/src/main/resources/application.properties

   Lines 10 to 12 in dbda6fd

   	quote.author=mahatma-gandhi
   	quote.tags.or=wisdom,happiness
   	quote.tags.and=famous-quotes

2. It looks like the QuoteResponse class is never used, rather the response body is parsed into an array of QuoteResponseItems. I would have expected the response to be turned into the QuoteResponse which would give you easy access to the list of QuoteResponseItems, without the need to mess with an array.

3. Consider putting the generated entities in a different package from the entities that you've written.

4. I'm curious about the reasoning behind using the java.net package and HttpClient instead of the javax.ws.rs. package and ClientBuilder. I'm asking because I think the best practice has been to use Java.ws.rs/Jersey for enterprise java applications.

Week 8: not yet. Looking for some clarification on the items above.

[ArchILLtect]

@pawaitemadisoncollege - response to feedback for week 8

1) quote.* properties

Those properties are active inputs to QuoteService. I thought you would appreciate this because you don't want them hard-wired. I will add comments to it to be more explicit. They’re read from application.properties using the good old PropertiesLoader and used to build the outbound request (author and OR/AND tag filters). I’ll add a brief code comment where the URI is built to make this explicit.

It just also happens to be temporary, because I plan to add a settings menu, which will allow the user to control what kind of quotes are pulled from the quote API. This will allow them to choose a specific Author (select element with multiple options) OR choose tags (which I will use checkboxes for). I just didn't have time to create that yet, so I got it at least to where it will be easy to proceed from.

2) QuoteResponse vs array mapping

That is exactly what roboPOJOgenerator gave me when I generated them with it. Here is what happened:

• I was using a different service when I generated it via RPG, and since it had a signature like: { "QuoteResponse": [ { ... }, { ... } ] }, RoboPOJO created QuoteResponse + QuoteResponseItem for that shape.
• I decided to switch services, because the first service wanted to charge me money for filtering responses (Author, Categories, etc.) and for no ridiculous throttling.
• I re-generated via RoboPOJO and just bypassed (was supposed to be temporary) QuoteResponse, because the new signature just returns a top-level array.
• I got distracted and forgot to remove the original QuoteResponse and rename QuoteResponseItem to QuoteResponse, which I will do now.

3) Package / naming for generated types

This is what I really struggle with. Can you give me some ideas of what to use instead, or something that can "teach" me some sort of naming scheme?

4) HttpClient vs ClientBuilder

I actually added that service back around Week 5 before we got to this exercise in class. When I researched how to implement it at the time, I found that using java.net.http.HttpClient is considered the modern, built-in approach for Java 17 and newer--though I could definitely implement a JAX-RS client version if that’s preferred for demonstrating the older enterprise standard.

The issue here is that I had assumed (and was wrong, obviously)->new app->modern approach. I tend to jump in early and build things ahead of schedule. This is a major reason I ended up purging spring from the project--it just makes it easier for you to ensure I am picking up the lessons of the class, and almost surely quicker for you to get through.

Eexpect these changes to the app:

• Remove/rename QuoteResponse/QuoteResponseItem.
• Add a comment in QuoteService where filters are applied (“config-driven, not hard-coded”).
• Add a "Default quote filters" comment in application.properties.
• Move generated DTOs to something like: "…external.model"?
• (Optional) Add a ClientBuilder variant for the same call if you want that shown instead.

[pawaitemadisoncollege]

1. So the service is configured to only return quotes from Ghandi? It seems to me that it would be more flexible if the caller could pass this information in.

2. can you clarify the endpoint being consumed? I saw two endpoints: http://api.quotable.io/quotes/random (which doesn't seem to be working - dns error) and https://zenquotes.io/api/random which jives with the 2 class response and avoids the array. Thanks!

3. Naming for classes from apis - use the reverse domain name like I showed in week 9: https://paulawaite.com/education/java113/Module2/Week8/Activity3.html#mapping-a-json-response-to-objects. For example, I generated the SWAPI classes into com.swapi.

4. Interesting. I'd like to review that resource as I'm not sure why the lower level client would be preferred. Since this course is focused on Enterprise level java and since we're using JAX-RS for producing services, it makes the most sense (to me) to use the same package for consuming apis. If you are going to use the HTTPClient, explain the reasoning in your class.

[pawaitemadisoncollege]

One more thing! I noticed when logging some exceptions exception.toString is used. Is there a reason for this rather than logging the entire exception so that you have the stack trace for reference?

[ArchILLtect]

1. Properties:

Yes, it was only set to return Ghandi quotes (set in application.properties)--but only for controlled testing. If author and tags are left blank in application.properties, it returns random quotes from any of the authors and/or categories (which use tags) available via the API. It is set this way intentionally, so it is not hard-coded, and because, again, it is temporary until I "add a settings menu, which will allow the user to control what kind of quotes are pulled from the quote API. This will allow them to choose a specific Author (select element with multiple options) OR choose tags (which I will use checkboxes for). I just didn't have time to create that yet, so I got it at least to where it will be easy to proceed from."

Also, I kept the property-based initialization as a placeholder for now, but the long-term plan is to replace those values with user-selected settings stored in session state.
I plan to implement a small “Settings” UI once I have met Checkpoint 2 that will let the user choose the author and tags, and then pass those options into the QuoteService as parameters — for example:

String quote = quotes.getRandomQuote(author, orTags, andTags);

That will give the “caller” full control of the quote parameters without needing to modify configuration files.

For now, those values are loaded from application.properties as placeholders so that I can confirm the service logic and URI building work as intended. Once the settings UI is wired in, those same parameters will be populated dynamically by the user rather than from the properties file.

Hopefully, that fully explains what is going on here.

---

2. Endpoint clarity:

Yes, http://api.quotable.io/quotes/random is the correct current site, which is why it is in application.properties. The other is just a default, in case the first (key: "quote.api.url" -- which is pulled from "/application.properties") doesn't work for some reason:

--> The "default value" is a fallback (made this dynamic also). I’m not sure why you’re seeing a DNS error — the endpoint works fine on my local environment (see screenshots below). It’s possible the API was temporarily down or blocking certain requests at the time. I verified both https://api.quotable.io/quotes/random and https://zenquotes.io/api/random before submission, but Quotable is the one currently active in my configuration.

--> This screenshot shows the service working with author=mahatma-gandhi

-->This screenshot shows the service working with the author prop set to empty.

---

3. Naming for classes:

Okay, here was my misunderstanding: I thought you named the package as "co.swapi" purely because you had only ONE purpose for that exercise--as there are no other packages, if I remember correctly--but I get what you are saying now. But also, here are my concerns about using that naming "scheme."

• URLs change, and there is a definite lack of control there when I don't own that URL. SAWPI even, for example right now:

• Also, what if I need to change services later--as I did already here once? Then I have to rename that package. Not a huge deal if I only have one file, but if I have more, later?

---

4. Preferred client:

You are 100% correct. I didn't mean that it is preferred for this class or in that specific case, but that it is preferred for more modern stacks--bearing in mind that I started the project with Java 17/21 and veered off course due to my rigid planning. And there was my huge mistake from the start of this project: I was behind, I had TOO much crunching down on me, and I made the mistake of thinking "new app=modern stack", as I said in the other issue. The fact that it is Enterprise Java should have been enough to make me stop and think about it, and would have been if not over-stressed. And I think that because I went off and kind of "found my own way", is the main point of misunderstanding right now--you may think I have ignored the material/lessons, when I truly have gone through it all, and the issue was that I had already went down the wrong path from the start and tried to keep matching it and sort of trying to work the exercises into the "modern" version as best as I could.

I also just want to mention — I hope it doesn’t come across like I “take issue” with the class processes or tools. That’s not the case at all. I really value what we’re learning here. I just tend to explore newer approaches when possible, and sometimes that means I branch out (out of scope) or get a little ahead of the curve compared to the examples. I’m trying to find a balance between staying current and staying consistent with the class expectations.

---

"5." Logging weirdness

Good catch — that one’s all on me. I used auto-complete while wiring up the logger and missed that it defaulted to .toString() for some reason, instead of passing the full exception. Normally, I include the full stack trace, so that was just an oversight on my part--plain and simple. lol I tend to use auto-complete on these smaller, repetitive lines, and then circle back after the method is fully wired up.

[pawaitemadisoncollege]

Thanks for the clarification @ArchILLtect - this helps a lot.

Following are the next steps:

1. If you are consuming 2 services, there should be a DAO for each one. I recommend you try doing one of these with ClientBuilder so you are familiar with that tech. If you land a job working with Java, it's likely you'll encounter this! I'll be interested in hearing how you find this compares with the java.net approach in Java SE.

2.The two services appear to have different response formats so these should each have their own response classes. (In industry we used reverse domain name for those generated class packages. Yes, that means there could be a future refactor if the service moves to a new domain and you want to keep the package name consistent.) Based on (https://zenquotes.io/api/quotes/random) and the documentation here: https://github.com/lukePeavey/quotable?tab=readme-ov-file#get-random-quotes.

3. You mentioned you were going to later allow the user to choose author - that's great, just build method to accept that parameter now and unit test it.

4. Test the "real" endpoints. If there is a reason not to hit the real service due to costs or rate limits, it is ok to use your mocks in addition. Note that you can disable individual tests if needed, but you should have a test for the real service to verify it.

5. With regard to the challenge of unit testing something that gives back random results - this is common - you can test to verify that something of a certain length was returned - check each field in the response object for a value. Testing the method that accepts the author param should make it easier to more accurately verify some values - like the author itself!

Hope that helps!