propose definition for a "not implemented" error status

[Travis Hein]

Can we define an error code for the situation where a method might not
be implemented ?

Perhaps, referring to section 5.1, something new like

code= -32604
message= Not Implemented
meaning= The method has not been implemented at this time.
(http code=501)

according toRFC 2626 [1], the HTTP status code "501" is well suited
for use to indicate something on the server side has not been
implemented yet.

For example, assuming there was a 'published' JSON-PRC definition of a
set of methods, that may be implemented by an arbitrary server-side
code language, and that some methods or features of the 'service
specification' might not have been implemented yet due to developer
time constraints.

So rather than returning a general internal error, which can mean
anything from server failure to application logic inputs error, it
might be convenient if the services developer had the option of
returning a NOT_IMPLEMENTED status,

that if another developer trying to connect to this service could see
error message NOT IMPLEMENTED from their client in the case when the
server has indeed not gotten around to implementing this method yet,
the developer would know that the error is not due to the way they
were invoking the request, but rather that service provider they are
trying to message to has not gotten around to implementing this
feature yet, and this may help focus the eventual support efforts
directed towards the service provider.

Looking forward to hearing your thoughts and discussions on this.

[Matt (MPCM)]

-32601 Method not found. The requested remote-procedure does not
exist / is not available.

This should cover that situation (?). If the method is not available,
adding a stub that says it's `not yet available` seems a bit odd to
me. I think I understand what you are saying, but either you conform
to the published list or you do not. A middle ground with a custom
error code does not seem straightforward to me...

--
Matt (MPCM)

[Alexandre Morgaut]

Be careful, this status code (501) is about HTTP method
implementations (PUT, DELETE, TRACE...).
You may define a JSON-RPC level error code, but on the HTTP level, the
client made a wrong request which is represented by the 400 status
code.

10.5.2 501 Not Implemented

(...) This is the appropriate response when the server does not
recognize the request method and is not capable of supporting it for
any resource.

[Travis Hein]

Yes, I guess that existing code will do.

I was confused in the terminology thinking method not found would be displayed if a method that does not exist at all was invoked,

where the case for a 'not implemented yet' error would be when a method that does exist, but has been not built yet.  I was thinking from previous experiences where enthustiac QA testing teams would tear apart a product release and build a huge list of errors, which included the parts that were known in advance as not having been implemented in this phase yet, so they aren't really 'new deficiencies'...  Or for situations when a developer new to working with a framework, might have learning curve trying to work with another open source project, where it also is a work in progress, and might be frustrating if a method does exist, but just doesn't work yet because it isn't completely baked yet in the implementation.

But I guess too that the additional message for that amount of selectivity is kind of too much detail, and that the exiting not exist / not available error should be good then.,

--

You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=.

[Omi]

Isn't the "Not Implemented Yet" state returned as an exception or
similar mechanism in libraries?

The point I'm trying to make is that the error can and probably should
be returned as an error of the method rather than using the protocol.
Anyway that's my 2 cents.

> > json-rpc+u...@googlegroups.com<json-rpc%2Bunsubscribe@googlegroups.c om>
> > .

[Travis Hein]

Yes, that was what I was implying, where if a method in a service returned a JsonRPCResponse message, it would be stubbed in to return an error response, of status not implemented.

Or in cases where a JSON-RPC request processor invokes an arbitrary method in the server implementation code, if that method was to throw some exception, such as a Java or language specific NotImplementedException,  the request processor could try.. catch on that exception and return the JsonRPCResponse message that is an error, of status not implemented.