Do people use Yada in combination with AWS Cognito? (I think obtaining JWT tokens via Cognito using those tokens for Yada authentication)

ok I cannot find examples, but it looks rather simple

we don't use cognito, but do use JWTs for yada auth ( with funcool/buddy ) - all very straightforward

@mccraigmccraig thanks for confirming that

I found these two links if anyone is interested. Sounds doable https://github.com/awslabs/aws-support-tools/tree/master/Cognito/decode-verify-jwt https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html

a question about versioning via Accept a la github API v3 https://developer.github.com/v3/#current-version

I would like to use Yada to process something like Accept: application/vnd.funcky-api.v1+edn

tbh we have an interceptor to retain raw payloads at the moment so I don't need yada to read the edn but just want to check whether there are any known issues with this approach - which is quite common in the API world

I can just parse the header myself and put the parts back on the ctx

I seem to recall adding support for that

do you remember what the support offered? ie did it allow routing per version?

or was it just adding the data to the context to allow for later interpretation (which is what I'm doing)

I have added a map {:name api-name :version api-version :data-format api-data-format} under [:request :accept-data]

It was making the parsing work for the spec of extension types

Might have been a pull request that I reviewed, I don't think we merged it

I don't think you don't need suffix support. You just declare in yada the versions you are able to produce and in the Accept header the versions you can process. Content negotiation does the rest.

https://www.infoq.com/articles/roy-fielding-on-versioning/

Oh, missed that you already have something that reads the edn

@malcolmsparks do you have an example?

apart from 'application/edn' where can I specify that the consumer expects v1 or v2? or are you saying that a client should never express that?

Ah, I see. You'd offer to consume either of application/vnd. funcky-api.v1+edn and application/vnd.funcky-api.v2+edn.

A v2 api wouldn't necessarily be different routes, or it might. The routes would be contained in the representation of the initial response from /.

That representation would reflect its version.

That's a problem if clients code themselves against specific URLs, rather than generating those URLs in representations.

Which is why Swagger/OpenAPI isn't REST, which prioritises evolution of services on the web. However, in-house services, codeveloped along with their clients, can benefit from establishing the OpenAPI contract up-front. I think that's still a poor strategy long term - not much progress made since IDL really.

Because ultimately, even in-house services can last decades.

But today's culture is dominated by moving fast and building 'MVP's

Tomorrow's culture maybe more cautious and spend thrift

the goal is mostly to express the fact that various clients in the wild will produce and consume v1 / v2 payloads without the need for out of band schemas so maybe the question is posed badly

if we find a bug or a security problem with the encoding of data by v1 we need a way to tell the customers to upgrade the SDK to v2

I'm happy to keep tending the sprawl on the back end 🙂