Paginated get requests

[sivan]

Hi I’m having a tough time with paginated API requests using http.get().

It seems Go panics but I can’t tell why.
“panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x40 pc=0x64cdc3]”

I do know that the first get request is made successfully. It seems to panic on looping.

Is there an easier way to do this?

Orders := OrdersResponse{}
var NextLink string
OrdersCall, _ := http.Get("https://" + APIKey + ":" + APIPass + "@example.myshopify.com/admin/api/2020-04/orders.json?attribution_app_id=123456&limit=250")

Paginate := 1
for Paginate == 1 {
	// If we got a NextLink call it.
	if strings.Contains(OrdersCall.Header["Link"][0], "next") {
		OrdersCall, _ = http.Get(NextLink)
	}
	OrdResio, _ := ioutil.ReadAll(OrdersCall.Body)
	OrdersCall.Body.Close()
	OrdJSON := string(OrdResio)
	OrdersResp := OrdersResponse{}
	json.Unmarshal([]byte(OrdJSON), &OrdersResp)

	Orders.Orders = append(Orders.Orders, OrdersResp.Orders...)

	if strings.Contains(OrdersCall.Header["Link"][0], "next") {
		i := strings.Index(OrdersCall.Header["Link"][0], ">")
		NextLink = OrdersCall.Header["Link"][0][1:i]
	} else {
        Paginate = 0
        break
	}

}

fmt.Println(len(Orders.Orders))

[skillian (Sean Killian)]

@sivan, there’s not enough context there to know what the problem is. Can you provide the full stack trace? Based on the addr value in that panic, it looks like the code is accessing a field in a struct somewhere that is nil. To narrow that down, we’d have to get more context.

[sivan]

Actually that is very helpful. I think OrdersCall is using whatever struct it’s getting back from the first API response, but the second response is different because it has additional headers. I would guess the first and last reponse don’t have a previous or next link respectively.

How can I find what struct is being used by the http client when OrdersCall is initialized? Or is there an easier way to go about this?

[sivan]

It turns out authentication was failing on the second call. Can be chalked up to bad error handling on my part.