Need advice for prototyping API

I am using ServiceStack to make APIs that the front end dev hooks up to Angular. I am used to working alone and making front and backend myself so there is some issues I am facing now working as team.

I have realised that if the front-end has to wait for fully functional endpoints then there is some delays and also some issues communicating what endpoints do.

I have been looking into the problem to see what people do and came across some articles discussing API prototyping using API designers. This lets you create the API and return mock data. I like the idea of this as front and backend can design it together and front-end can work with the mock data.

Is the a way to get this working with ServiceStack?

I saw a couple of designers that worked with Open API and Service Stack supports Open API. In the documentation it mentions the front-end client can be generated from Open API using AutoRest NPM package but what about the backend Service Stack services?

Is there any way to build the API in a designer and then scaffold that into Service Stack?

It’s not clear what the actual question is? but generating an API with Open API is possible in ServiceStack just as it is with any Open API endpoint, but that’s what other APIs have to resort to using.

ServiceStack Add ServiceStack Reference is a far cleaner, simpler and superior solution requiring less code-gen but generates richer DTOs (e.g. preserves interfaces, inheritance and attributes for .NET langs).

ServiceStack’s DTO-first design also lets you develop the service contract first before implementing either the client or back-end implementation, where your clients can use the DTOs with the mock client IServiceClient which you can use to return mock data until the back-end Service is implemented.

I don’t know what you mean by API designer, in ServiceStack you define your APIs with well-defined Request + Response DTOs, using a C# class is already a DSL for designing Service Contracts, this isn’t something you want a designer to do which is going to make the end result worse just as when people tried and failed to do with UML which ended up being a waste of time that generated worse code and caused more friction for implementors.