smithlamar / route_tracker_api Goto Github PK

Compile time checking for the URL components and parameter formats will probably be something that I thank myself for later (or something that I decide was a terrible idea!).

https://github.com/smithlamar/route_tracker_api/tree/master/src/test/java/com/lamarjs/route_tracker

As it stands, all parsing of CTA requests and desirialization of the objects contained within each payload is handled manually (albeit using Jackson core elements). The general goal is to see how far we can get with annotations and either RestTemplate and/or ObjectMapper to handle the deserialization and possibly the calls to the CTA for us.

This would make BustimeAPIRequest more lightweight and easier to reason with overall. The examples I've seen so far of this sort of implementation involve very pretty pojos that get deserialized from the Json response. It seems to get trickier when collections that use generics are the destination for the deserialized response. It gets trickier more so because some of these generic collections are contained within properties of the BusLine objects. A BusLine's directions is a list of Direction objects. Each Direction within BusLine.directions contains a List of Stop objects.

CTA response example:

`	"bustime-response": {
		"routes": [
			{
				"rt": "1",
				"rtnm": "Bronzeville/Union Station",
				"rtclr": "#336633",
				"rtdd": "1"
			},
			{
				"rt": "2",
				"rtnm": "Hyde Park Express",
				"rtclr": "#993366",
				"rtdd": "2"
			},
			{
				"rt": "3",
				"rtnm": "King Drive",
				"rtclr": "#009900",
				"rtdd": "3"
			},
                        ... # more and more routes
                    ]
      }
`

This response ties to what is essentially a List object, but only part of the data required for a complete BusLine object as we've defined it is here. The data for the directions property is retrieved from a different endpoint of the CTA API but we are treating it as just another component of a BusLine. We can probably use @JsonIgnoreProperties(ignoreUnknown=true) to keep the parser from failing where it doesn't find matching properties. We can also set unwrapwroot for deserialization in application.properties to deal with the wrapping "bustime-response" root that is a part of every response.

RestTemplate can theoretically take our class and map the Json response to it in addition to making the request with a supplied URL. The issue is when the class in this case is a generic collection. RestTemplate needs the type information but type erasure gets in the way when generics are involved. This seemed to be an issue that required some inelegant solutions in previous versions of Spring. I need to experiment a bit to figure out how to get this to work well without dirtying up the BusLine class with a ton of Json focused annotations or logic that ultimately is harder to reason with than manually deserializing the response to begin with.

Another concern is that we still need to be able to differentiate payloads from the CTA that contain error messages from those that have payloads that we actually want to build objects from and I haven't seen any indication that we can dig through the response returned from RestTemplate any easier than the way it currently is just by manually sending the request and checking the keys that are present.