Webservice - How to get 404 (Not Found), Response

[Poul]

I have A Webservice using json and a REST GET If i ask for a Valid code

Code: [Select]

GET /DatabaseService/dbCommodity/klbit responds as expected with

Code: [Select]

HTTP/1.1 200 OK
Date: Fri, 23 Sep 2016 21:14:44 GMT
Server: NetTalk-WebServer/9.13
Content-Length: 158
Content-Type: application/json
Set-Cookie: SESSIONID=kM4TrveL7m2KOy7c; path=/; HttpOnly
Connection: close
X-Frame-Options: sameorigin

{
"dbCommodity_response" : {
"commodity_details" : [
{
"commodity" : "NEWSPRINT",
"pouom" : "MT",
"classid" : "NWSP"
}
]
}
}
but if i ask for an invalid code

Code: [Select]

GET /DatabaseService/dbCommodity/BADCODEit responds like this:

Code: [Select]

HTTP/1.1 200 OK
Date: Fri, 23 Sep 2016 21:15:29 GMT
Server: NetTalk-WebServer/9.13
Content-Length: 67
Content-Type: application/json
Set-Cookie: SESSIONID=Il7Ozels3LqdiNk8; path=/; HttpOnly
Connection: close
X-Frame-Options: sameorigin

{
"dbCommodity_response" : {
"commodity_details" : null
}
}
Which is sort of true but should it be responding with  404 (Not Found)?
rather than 200? And where/how is the best place in a NetwebServiceMethod to do this?

tia poul

[kevin plummer]

Hi Poul,

404 is when a web page is not found so irrelevant in your example.

Technically I'm not sure returning a null or error response message in your case is the right approach.

Cheers,

Kevin

[Bruce]

Hi Poul,

>> Which is sort of true

actually, it's exactly true <g>.

>> but should it be responding with  404 (Not Found)?

REST has this idea of making "parameters" (ie "values") part of the URL. Of course if a traditional URL is not found then you get a 404. But this URL is really a composite of "location" and "data". In this case the _location_ part is fine, so you should get a 200, the data part is bad, hence the Null.

You can still set the return code if you like though. I don't recommend 404, but perhaps some code other than 200 might be appropriate for your service. (Bear in mind though that this just complicates your documentation, and complicates code on the client side.)

p_web.ReplyResponseNumber = 123

>> And where/how is the best place in a NetwebServiceMethod to do this?

Basically anywhere. (before the reply is sent out.)

cheers
Bruce

[Poul]

REST with JSON, is new to me but it is growing on me quickly(parameters part of the URL), but i have yet to find definitive documentation (that i can decipher). It was the idea that verbs PUT , GET, POST and  DELETE, can fit into a std CRUD model using simply a URL, that caused me to perhaps over think this, but i see the benefits of allowing basic operations without using additional parameters.

... and complicates code on the client side.

seems to be a REST guiding principal, to keep it simple for the client., and a good enough argument, currently I am writing the service to an unspecified client, so i can dictate the interface so long as i can still call it REST (and be somewhat  politically and technically correct). I was not looking for an arbitrary value but something that matches a standard or convention.200 and 400 and 404 all seem possibly valid, depending on ones argument. 204 (Content Not Found) sounds plausible but probably more wrong than right. I had found something  that suggested 404 was the expected value for REST response where the Record/Rows was not Found..

You are saying for most REST client developers, 200 would be the more acceptable (expected)  response in this case, and is certainly the way NetTalk will do  (and expect) it  by default.

Note: the webservicemethod is to soon (Unless i  duplicate some code),  SO  if i needed, i could examine the jsonresults object,after BUILDRESULT and set the response.before the sendpacket.otherwise you will send 200,

poul

[Bruce]

Hi Poul,

>> growing on me quickly

yes, that's what happened to me as well. It's a lot simpler and cleaner than what SOAP has become.

>> but i have yet to find definitive documentation

That's probably because REST is not a "standard" but a "concept". Actually it's a mix of ideas, and each server is basically free to implement things however they like. There's no REST standard, and thus no way to say that this service is definitively REST, and that service is definitively not.

>> so long as i can still call it REST (and be somewhat  politically and technically correct).

yes, the goal here is to write the server, and be able (with a straight face) to call it a REST server. To do that you should mostly follow REST conventions as closely as possible. But that doesn't preclude it being different here and there (*). I've certainly seen some variation from one server to the next.

>> ... keep it simple for the client.,

yes. So you can set the response code if you wish, but don't necessarily make this the _only_ way the client knows something went wrong. Send an error in the response as well. The client can then parse the number, or the reply, whichever is easier for them.

I found this;
https://msdn.microsoft.com/en-us/library/azure/dd179357.aspx


(*) - for example, the use of a session cookie is not very RESTy. Some might argue quite un-resty. On the other hand it can make your API faster if you don't have to re-authenticate on each request. So many services allow a "token" to be issued to the client which allows a login to "persist" for a while. and whether the token is a session cookie, or just text re-sent with every request it's the same thing. But one would not call a service that had this feature "not REST" simply because it had this feature.

Cheers
Bruce