[Corona] Corona explore endpoint and web-interface?

[Geert Josten]

Norm,

I am not arguing the fact that process-request is checking things. The
more the better I'd say, so that is okay. Go ahead and check everything if
you must.. ;-)

The thing is that it makes a lot of sense to _do_ use both halves. They
seem to be there for a purpose. But to me it is giving the impression that
it is designed such that step 1 never complains, just return a matching
endpoint or not. So it looks like you would have to rely on step 2 to do
the complaining part. But as said, if step 1 already filters out any
mismatches, then there is nothing left to complain about.

About Corona: to me it would make sense if the endpoint configuration is
accurate, but that results in endpoints not being matched, and Corona
bailing out with a non-informative error. Also, the endpoint code is doing
a lot of checks the REST library is doing as well. Sounds pity to me..

I am just looking for a way to get 'the best of both', having the REST
library doing the majority of the checking, and still getting sensible
messages. It can be achieved by making the rewrite throw errors, but not
sure that fits the architecture and recommended use of the REST library..

Kind regards,
Geert

-----Oorspronkelijk bericht-----
Van: Norman Walsh [mailto:Norman.Walsh at marklogic.com]
Verzonden: dinsdag 13 december 2011 15:40
Aan: Geert Josten
CC: Colleen Whitney; Ryan Grimm; Corona Email List
Onderwerp: Re: [Corona] Corona explore endpoint and web-interface?

Geert Josten <geert.josten at dayon.nl> writes:

> With 'design flaw' I meant that if the rewrite already makes sure uri is
> correct, method is supported, parameters match and have correct type,
mime
> is correct, conditions are met, etc, then there is nothing left for the
> process-request to complain about (so nothing to raise errors about).
> Unless the rewrite doesn't check everything, and the process-request is
> more thorough. I'd have to take a closer look to make sure.

Well, there's nothing that says you have to use both "halves" of the
REST library together and there's nothing that says you have to be
consistent in the endpoint descriptions that you use.

You could, for example, say that the "foo" parameter was optional in
the endpoint description used by the rewriter and then say that it's
required in the actual endpoint. That would be inconsistent. The REST
library has to do *something* about that inconsistency.

The endpoint is trying to build a map out of the parameters. If it
encounters a parameter described as required that's actually missing,
it could ignore the error, but that seems wrong. I want to be able to
write the code that does the work of the endpoint with the knowledge
that the parameters have been checked.

If anything, the fact that process-request doesn't also check the
method, accept headers, etc. is the bug.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 413 624 6676
www.marklogic.com