Is this API for ECDSA signature verification consistent with NIST test vectors? I'm trying to use code from "Easy ECC" package (a github project), for ECDSA-verifying a signature.
The problem I'm facing is that the API assumes a public key length of N+1, which is different than NIST test vectors, where the public key is composed of 2 components (Qx, Qy) which are N bytes each.
(N is the number of bytes for the chosen derivative. For example, for P-256, N is 32).

To be specific, here is the API (ECC_BYTES is 32):

int ecdsa_verify(const uint8_t p_publicKey[ECC_BYTES+1],
    const uint8_t p_hash[ECC_BYTES], 
    const uint8_t p_signature[ECC_BYTES*2]);


and the corresponding NIST "verify" test vectors are:

P-256,SHA-256  
Msg = (omitted)  
Qx = e424dc61d4bb3cb7ef4344a7f8957a0c5134e16f7a67c074f82e6e12f49abf3c (32 bytes)  
Qy = 970eed7aa2bc48651545949de1dddaf0127e5965ac85d1243d6f60e7dfaee927 (32 bytes)  
R = bf96b99aa49c705c910be33142017c642ff540c76349b9dab72f981fd9347f4f (32 bytes)  
S = 17c55095819089c2e03b9cd415abdf12444e323075d98f31920b9e0f57ec871c (32 bytes)  
Result = P (0 )  


R and S are 32 bytes each and this is consistent with the API signature length of 2*N = 64 bytes.
Qx and Qy are also 32 bytes each and this is not consistent with the API's public key length of N+1 (33 bytes)

My question is: Does this API conform to ECDSA standard ? Eventually, I will have to test it with test vectors like the NIST one above.
Public keys in this system are very sparse: for any $x$ value there are at most two possible $y$ values satisfying $y^2 = x^3 + ax + b$ where $a$ and $b$ are the curve parameters, since the equation is quadratic in $y$.  (And $x^3 + ax + b$ has a square root at all only for some values of $x$; by Hasse's theorem, the number of points on the curve can't be very far from the number of elements in the coordinate field, so only about half of the possible $x$ values work.)

The signature API you're using presumably deals only in compressed public keys, which have maybe some formatting metadata and likely a single bit determining $y$ in one byte, together with 32 bytes to determine $x$.  For example, in the ANSI X9.62 format, the first byte is 0x02 for an even $y$ value, or 0x03 for an odd $y$ value; then the remaining 32 bytes encode $x$.