Live data from Hacker News

Write OpenAPI with TypeSpec

blog.trl.sn

11–20 of 74 posts

Re: Write OpenAPI with TypeSpec

#11
As someone who has used JAX-RS (Java) and ASP.NET, APIs are basically created with these kinds of annotations right in the language.

    @GET
    public Character getCharacter(@PathParam("id") int id) {
        return db.getCharacter(id);
    }

That's very similar to TypeSpec's

    op getCharacter(@path id: safeint): Character;
Java and C# classes already have the type information that you'd be getting from a TypeSpec:

    // TypeSpec
    model Character {
      name: string;
      id: safeint;
      status: "Alive" | "Dead";
      class: Class;
    }

    enum Class { warrior; wizard; }

    // C#
    public class Character {
      public string Name { get; set; }
      public int Id { get; set; }
      public Status Status { get; set; }
      public CharacterClass CharacterClass { get; set; }
    }

    public enum Status { Alive, Dead }
    public enum CharacterClass { Warrior, Wizard }
But with C#/Java you don't need to write the spec and make sure that it stays in sync with what your endpoints are actually doing. TypeSpec looks a lot better than writing YAML by hand, but I'd still rather something that was tied to the actual code that will be executing so that things are never out of sync or wrong.

Re: Write OpenAPI with TypeSpec

#12
Cool, it certainly feels like there's some unrealized better way to describe APIs -- but the part that's more interesting for me is the codegen story? Or some way to validate the service I implemented is actually conformant?

I guess for now it translates to OpenAPI, but the footnote implies that TypeSpec-driven codegen could be better. Maybe more is coming soon?

Re: Write OpenAPI with TypeSpec

#13
post #7

I wonder why this isn't written in Typescript directly so as to handle documentation, validation and type definitions in one go. Especially if you want to reuse type definitions of objects elsewhere in your code. An API request or response usually do not contain the exact model attributes. Only the public facing ones which are then often filtered down some more, depending on the user making the request (and their rol…

> I wonder why this isn't written in Typescript directly so as to handle documentation, validation and type definitions in one go.

I suspect they want TypeSpec to be more runtime agnostic (as also tends to be the preference with TypeScript). Specifically to support arbitrary validation/serde.

Having written a fully integrated generalized solution (runtime-defined schema -> parser, types, documentation, serializer), by far my biggest regret the first time around is coupling it so closely to a particular schema runtime. Partly this is because I have bigger dreams for designing a schema system purpose built for the task (I had previously piggybacked on io-ts, which worked but it took considerable non-essential effort and complexity); partly it’s because there can be significant tradeoffs between different runtime solutions in terms of performance and ergonomics.

Re: Write OpenAPI with TypeSpec

#14
post #7

I wonder why this isn't written in Typescript directly so as to handle documentation, validation and type definitions in one go. Especially if you want to reuse type definitions of objects elsewhere in your code. An API request or response usually do not contain the exact model attributes. Only the public facing ones which are then often filtered down some more, depending on the user making the request (and their rol…

Our first attempt at a TypeSpec-like thing was in fact a TypeScript dialect! It works great for simple cases, but at the limit it falls over for a number of reasons. HTTP needs a lot of metadata that isn't found in TypeScript, things like HTTP verbs, query/path params, headers, routes, etc. API patterns also need their own metadata, like for pagination you need to know various bits of metadata that describe how to paginate an endpoint. Also many things in the TypeScript type system and stdlib don't apply in the context of API descriptions, so we needed a subset.

So after going down this road for a while, we found we were in a place where the syntax was actually very complex, with metadata spread between deeply nested generic type instantiations and JSDoc comments, and didn't feel at all like TypeScript. This didn't align with our goals of having something simple and easy to learn for all devs.

So I wrote the first implementation of a custom language in a day and folks really liked the direction. 4 years later, here we are!

Re: Write OpenAPI with TypeSpec

#15
post #9

This is cool! I made a similar project to this one when we switched from GraphQl to regular REST at $work but decided to drop it since I didn't have the bandwidth to work on it. I see editor support for VSCode, but is it backed by an LSP or is it VSCode only?

It's LSP, and we also have a VS extension in the marketplace.

Re: Write OpenAPI with TypeSpec

#16
post #2

This is typical Microsoft - overly complicated solution in search of a problem. Yaml and Json are beloved for a reason - they're simple and effective.

Just because you don’t have the problem it’s solving doesn’t mean the problem doesn’t exist.

Re: Write OpenAPI with TypeSpec

#17
post #11

As someone who has used JAX-RS (Java) and ASP.NET, APIs are basically created with these kinds of annotations right in the language. @GET public Character getCharacter(@PathParam("id") int id) { return db.getCharacter(id); } That's very similar to TypeSpec's op getCharacter(@path id: safeint): Character; Java and C# classes already have the type information that you'd be getting from a TypeSpec: // TypeSpec model Cha…

This is the code-first vs schema-first debate. Both have their pros and cons. Personally a die hard advocate of schema-first.

Re: Write OpenAPI with TypeSpec

#18
What are people's thoughts on this vs AWS's Smithy?

We've been looking to buy into Smithy heavily as we no longer have the appetite to deal with OpenAPI and it's horrendous ecosystem.

Re: Write OpenAPI with TypeSpec

#19

Question for the author, why not fully adopt TypeScript? Ie have TypeSpec be a well-defined, limited subset of TypeScript? At first glance, it seems to me that a model maps to an interface, an op is a function, and an enum is a string literal union. I understand that you can’t express everything that way, eg annotations, but you could get pretty far with putting those in JSDoc comments, no? I could see a big practica…

I answered in more detail in another comment, but we actually tried this first, and couldn't make it work for the kinds of complex APIs we deal with in Azure. But, it worked great for simple APIs, and I hope someone releases such a tool at some point.

Re: Write OpenAPI with TypeSpec

#20
post #12

Cool, it certainly feels like there's some unrealized better way to describe APIs -- but the part that's more interesting for me is the codegen story? Or some way to validate the service I implemented is actually conformant? I guess for now it translates to OpenAPI, but the footnote implies that TypeSpec-driven codegen could be better. Maybe more is coming soon?

The author has an example repo demonstrating some of the early support for codegen. https://github.com/bterlson/typespec-todo

Server side codegen is also one the horizon and is a key way to keep the spec and service in sync. So many possibilities here!

Post reply on HN