Question: Different I/O for different methods

Hi,

I’ve started trying to use this module to manage my endpoints since I love the philosophy of how it’s setup. I have a question about a use case.

For an endpoint with multiple methods (i.e. post and get) is it possible to have an input and output for post that is different than the input and output for get? Or, I guess a way to attach different endpoint definitions to the same route would also work?

[glitch452]

I looked it over and, this seems like a great solution. If I understand correctly, it allows a complete endpoint definition for each method on a specific route. That would let someone have specific input and output schemas, which clearly solves this problem, but it should also allow specific middleware or even a specific result handler to be configured for each method, which is great, since that enables maximum flexibility while maintaining the simplicity of the endpoint definitions.

What I ended up doing, for now, was something similar to the suggestion 2. I set the input schema to be an empty object with passthrough enabled, then I used the method middleware to determine the method, then I parsed the input separately for each method. This is a little bit of a janky workaround, but it does get the job done! I haven’t started working on the OpenApi docs yet, but being able to automatically generate documentation for the endpoints would be really nice, and it looks like this tool can do that too! I would assume that these workarounds would make the documents less helpful though, and defining specific inputs and outputs for each method would allow the docs to also show those details, which would be great!

Just to give you some more background info, here’s the general way we have our endpoints setup.

• For creating objects we use the POST method at the plural of the object type. i.e. POST: /v1/users This returns the object that was posted (plus any meta data such as the database id)
• For querying for objects we use the GET method at the same route. i.e. GET: /v1/users?name=jane%20doe This returns a list of the objects. These two cases already create a need for the different IO schemas.
• To PUT, PATCH, and DELETE items, we use the id of the item in the path. i.e. DELETE: /v1/users/1 The DELETE method would use the 204 status code, which would have no body on the response, and the PUT and PATCH methods would return the full item with meta data.
• There are some occasional special cases, for instance, we allow users to download some data in a csv or ical format, which just returns a string body and sets some headers on the response for the appropriate content type. Maybe I should log a separate issue for this, but the way I implemented that was to have an output schema of { body: string, headers: Record<string, string> } and then I have a specific response handler to return it properly. I’m not sure how the OpenAPI parser would handle that, but it would be nice to be able to either set the output schema to simply be a string and then have another method for setting the headers (possibly just a middleware that makes a function available to the endpoint to set them, or a more general way to pass meta data to the response handler) or to be able to specify a key on the output schema that is used to define the actual output schema when generating the documentation.

So, our routing looks a little weird, but it works! Here’s how I set it up for one of our services:

const v1_router: Routing = {
  courses: {
    summaries: courses_summaries, // Special case for a specific return format
    query: course_query, // Special case with specific parameters required (returns 1 item)
    ':id': course,
  },
  schedules: {
    generate: schedules_generate, // Special case that receives post data and does some computation
    download: schedule_download_post, // Downloads (csv/ical) an anonymous schedule, which is assembled based on the post data
    '': schedules, // Has 'get', 'post' assigned to it
    ':id': {
      '': schedule, // Has 'get', 'patch', 'delete' assigned to it
      download: schedule_download_get, // Downloads (csv/ical) a specific schedule that is saved in the Db
    },
  },
};

Thanks again for getting back to me on this and for actually putting in the work on the PR. I really like how you’ve architected this library, and your solution does seem to be just as elegant. … Ps. If I do have some other use cases that come up, and I think it’s something I could tackle, I’d totally be willing to create a PR! This one seemed a little involved and I wasn’t sure if you were willing to open the tool up to be more generic or if you preferred to keep it more specific.

[RobinTail]

the feature released in version 1.2.0