Possible to specify response as combination of status code and body about claudia-api-builder HOT 25 CLOSED

As promised, here are my thoughts on an implementation of multiple error responses.

from claudia-api-builder.

@gojko thanks for the detailed response.

For now I've taken to using a post deploy step, as you mentioned. It's a bit of a hack as I didn't have enough time to look at creating a PR, but it works.

If anybody is interested, the code for my API is here.

One thing I had to also do was to set the error and success codes to the same value, as otherwise claudia sets the default response to return a 500. This often catches all of my errors, regardless of whether I have other regexes in place, this seems to be a quirk of how API Gateway works. I then had to ensure that all of my errors were returned with a prefix in the message, so I could set up my error responses to match the given pattern.

I have some thoughts about how errors could possibly be handled in a more generic way at the claudia level, based on some of my reading around this subject. I'll try to jot these down over the next few days, probably in a separate issue, for consideration!

from claudia-api-builder.

my implementation is ready 🎉

Api Errors: https://github.com/phips28/claudia-api-errors
@gojko can we move this 'claudia-api-errors' module to your claudia/ repo? and add it to npm?
error on transfering.. see gitter

Claudia: PR: claudiajs/claudia#69

from claudia-api-builder.

we could do this but it would be necessary to map messages to individual codes similar to this:

api.get('/', function () {
   if (isBadRequest) return { "message": "Bad request" } // 400 
    if (isForbidden) return { "message": "Forbidden" } // 403 
    return { "message": "Success" } // 200
}, {error: {'Bad request': 400, 'Forbidden': 403 }}

or alternatively

...
}, {error: {'400': 'Bad request', '403': 'Forbidden' }}

Lambda requires each http code to be set up in advance and mapped to a unique regex error message, so the codes would have to be listed somewhere in the config.

from claudia-api-builder.

i'm closing this due to lack of response; if anyone wants to pick this up in the future, please reopen the issue.

from claudia-api-builder.

Would really like to have this feature. Possible to reopen?

from claudia-api-builder.

I did a bit of investigation on this earlier, and I think this is technically not possible with Lambda + API Gateway. From what I can see, only one code can be used for a successful response, and error responses need to be selected by regex matching on the error message, which all needs to be declared upfront. I don't see a way how this can be implemented in a way that is generic enough to cover the use case reasonably.

If you can manually create a mapping template in API gateway and a lambda function that works the way you want, we can discuss how to make Claudia automate that process.

from claudia-api-builder.

I'm evaluating Lambda/API Gateway and potentially claudia.js as an option for migrating off Heroku (where I currently run an Express.js API). I'm not hugely familiar with any part of this stack as yet.

The API I want to bring over has endpoints with multiple error responses — e.g. 400 for missing authentication parameters, 401 for lack of authorization, 404 for non-existent resources, as well as 500 for unexpected errors. (It seems that the 4xx codes might ideally be generated in an intercept function?)

Anyway, @gojko's last comment makes it sound as though this might be just about workable (although the RegEx matching by API Gateway sounds horribly hacky). Can you explain a little more about how this could work — and whether it would be possible to extend claudia.js to support this without having to manually create mappings as you suggest above (I don't need a commitment that you would do it, but it would be useful to know whether in principle I could).

from claudia-api-builder.

@jawj modifying claudia to support a hash-map of error regex->response code would be relatively simple. all it would have to do is create multiple error response mappings instead of a single one, somewhere around like 232 of src/tasks/rebuild-web-api.js

the bigger problem is that this is potentially error prone and not that deterministic from the behaviour side of things. The regex will be matched on the error message, so in theory it's possible to include the wrong word in a message and match it against an unwanted response code. API GW/Lambda integration is unfortunately quite hacky in that part

from claudia-api-builder.

@gojko Maybe we should keep this open, it was about the first thing I ran into that totally stumps me about Lambda and API GW. I guess many people are going to look for it. Returning a 500 when someone is just requesting a non-existent resource completely breaks any REST scenario.

from claudia-api-builder.

@tnolet I tend to keep issues open if someone is actively working on them. Otherwise, they just become a dumping ground. If you want to do the code and submit a PR, I'm happy to reopen this and guide you through that.

from claudia-api-builder.

+1, the handlers should support return dynamic http status code, rather than each handler fixed success/error the only 2 possible status codes. the ApiResponse can hold the expected response code. for exceptions, I don't have idea how to make them hold status code yet.
and there should be some specific prefix format be defined to match the generated regex to get those code passthrough

from claudia-api-builder.

This would be super useful. Would make ClaudiaJS API compatible with REST APIs. 500 errors aren't cool :/

from claudia-api-builder.

What about a custom header eg "X-Status" that could be re-written by a mapping template, that would then allow a fairly clean implementation such as:

return new api.ApiResponse('Not found', {'X-Status': '404', 'Content-Type': 'text/plain'});

from claudia-api-builder.

@brightsparc that's not easy as Lambda+API GW has only 1 success code (default) and error code maps work on regex of error messages. As far as I can tell, there is no way to rewrite the status code, because status codes are used to select templates, not the other way around

from claudia-api-builder.

Regarding your initial suggestion of mapping error codes to message. Is that still a possibility?

from claudia-api-builder.

@aleemb that's still a possibility, the change should be in tasks/rebuild-web-api.js, and set up several error templates for all the different combination of codes/messages

from claudia-api-builder.

I'm interested in this too, not least because currently on the call to claudia update any manual Integration/Method Response configuration in the API Gateway is blown away. This makes it impossible to use even a custom mapping at present.

from claudia-api-builder.

@fiznool if this is important for you, I suggest submitting a PR.

This change should be relatively simple. Instead of just a single error code before line 257 of rebuildWebApi, the code needs to cycle through a list of mappings and submit them. Line 257 adds the default error response (pattern is blank), but you can add alternatives before it, with different patterns.

The config could be something like:

{ error:  { additionalCodes: [{ code: '404', contentType: 'application/json', pattern: 'NotFoundException'}, { code: '403', contentType: 'application/json', pattern: 'NotAuthorizedException'} ].

The test should be something like this one: https://github.com/claudiajs/claudia/blob/master/spec/rebuild-web-api-spec.js#L728

Also, add a test to the validatePackage spec to ensure stupid mistakes (such as double patterns or codes, reusing codes from the default list, empty patterns) are stopped before the API even starts deploying. It might also be useful to add a successful fully configured example to the kitchen sink parsing test, which is just a smoke test to validate that correct configurations pass validation

from claudia-api-builder.

@fiznool btw, if there's something you want to configure outside of claudia functionality, it's best to automate it as a post-deploy step, so claudia does it for you after each deployment. that way you don't have to worry about manual stuff being wiped out, or someone not doing it properly when you need to deploy a new stage.

from claudia-api-builder.

Any news regarding @fiznool 's thoughts? plans to implement it soon?
We could help.

from claudia-api-builder.

@phips28 I've updated my gist to include the latest plan, as discussed on gitter. Please let me know if you have any questions, I don't know how well I've explained everything!

Unfortunately I'm struggling to find any time to work on this, I haven't started any coding yet. So if you are able to work on this, that would be ace! 😄

from claudia-api-builder.

@fiznool started working on this now. But first I have to figure out the whole claudia setup/config on deploy.

from claudia-api-builder.

dynamic Error handling with statusCode support: (w/o tests&docu so far)
https://github.com/phips28/claudia
for updates read: https://gist.github.com/fiznool/27fcd362250ce668986a29ad79b59b03
If you can help me to improve it tell me ;) thx

from claudia-api-builder.

Awesome @phips28 I've added some comments in the gist.

from claudia-api-builder.