-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Add @encode
decorator
#1899
Conversation
Changes in this PR will be published to the following url to try(check status of TypeSpec Pull Request Try It pipeline for publish status): Website: https://cadlwebsite.z1.web.core.windows.net/prs/1899/ |
@timotheeguerin Could you help on the differences for below two statements? Are they equivalent?
|
Hey @MaryGao they are kind of equivalent for what it means over the wire but they are not equivalent for what you’d expect in the client. In the encode case you are saying that property is a date time conceptually and so would want to represent that in the client/server code. in the format case you are saying it is a string conceptually but it happens to be in the pattern of a rfc7231 date time. So in this case the client/server should only represent it as a string. i would think of format as a know pattern for string and that’s it. You shouldn’t do anything special about but validation(if you are doing validation) |
@timotheeguerin One more follow-up question, what is the expected string format if a typespec
|
@MaryGao it depends on the protocol and other things, For http there is documentation about all the default encoding of non primitive types here https://microsoft.github.io/typespec/next/standard-library/http/encoding#utcdatetime-and-offsetdatetime |
@timotheeguerin I might miss something, in the offsetDateTime description, it gives an example of "April 10th at 3:00am in PST" which should be rfc7231 by default as I understand it. https://github.com/microsoft/typespec/blob/main/packages/compiler/lib/lib.tsp#L108-L111 but in the documentation, it says the default format for offsetDateTime is something like "2022-10-25T07:20:50.52+07:00" which by the way is also not the standard rfc3339 format if I understand correctly ? |
In the first doc you linked it just shows the concept of a zoned date time that string is not rfc7231 either. |
It is rfc7231 only when used as a header, otherwise rfc3339. Can you point out the part of the example that is invalid? |
"+07:00" inside "2022-10-25T07:20:50.52+07:00" ? |
It is no? https://ijmacd.github.io/rfc3339-iso8601/ |
You can see the offset syntax in the grammar here also: https://datatracker.ietf.org/doc/html/rfc3339#section-5.6 |
Got it, Thank you all for the pointers. |
fix #282
Examples
Specify uuid, email, ipv4, ipv6
Specify base64 or base64url encoding
Specify serialization using rfc3339 standard
Specify serialization using rfc7231 standard
Specify serialization using unixTimestamp
Specify Duration serialized as seconds
Formats that move to
@encode
Deprecate using
@format
onbytes
base64url
base64
Logic for emitter:
@encode
decorator@encode