Although the the stock market-information is a data-object, it is generated by a service, and because Rest is (mis)used to communicate with services the service must be seen as the addressed resource. If the service is out of order, or the address to the service is misspelled a 404 would be in its place (Restlet does that out of the box. And that is right, According the Fielding, the service is the resource, not the data it produces.
"Any information that can be named can be a resource: a document or image, a temporal service" But when the service responses with information, f.e. a specific share is removed from the market, so there is no further information, or the share is not present at that market, then is that information. The services runs properly and it gives information. What can be wrong then? The problem is that Rest was meant to be for resources, as you say, as a webserver, the web was also meant for resources, static HTML-pages, that is where the http-status (1.1) is about, since it was designed in 1999. Bit this is not the case anymore. It is often an interface to a service instead of a resource, and according to Fielding, so the HTTP-status must say something about the service, not about, the information a service provides. By the way, last Sunday I linked to a document which interpreted the Fielding dissertation like I do. And an argument on this list came up that that link was to a document from 2003, thus, too old. But the Fielding dissertation is from 2000, 3 years older. Anyway, we are using Rest as an interface to services, so the status must be treated as such. As long as the service is found and responds to a GET with information, it should be treated in the resource-context as a resource that was found and in well state. That is my opinion, and I know not many use Rest this way, so we have to think about that. But isn't that all about OpenEHR, if the argumentation would have been: Do as others do. There wouldn't have been OpenEHR at all. I think, because, Rest is not a standard, it is legitimate to use it in another way then most people do, as long as you have a consistent process-model. Let us remind that the way Rest is nowadays used, does not represent a consistent process-model. It returns 404 because of a not found service, and it can return 404 on a found and properly functioning service, which returns information. It was also mentioned in the discussion, is Rest the way to communicate with a service oriented architecture, wouldn't SOAP do better? Because SOAP handles services as Rest should handle them. Is it possible to find a way to have Rest act more like a service interface? I think this is easy to do. But we have been through this discussion, I just wanted to reply to Erik who referred to Fieldings dissertation, and now it seems that that dissertation can as well be interpreted into my idea about Rest. Bert On 23-01-15 10:39, Ralph van Etten wrote: > Hi Bert, > >> So, if the content contains the information that no person with that ID >> is in the system, then that is information, everything went well, the >> class did its work without error, then that is not an error, and one >> could argument that 200 should be returned, or maybe 204, and not 404, >> which means that the resource to look for (which is the call handling >> process/class) was not found. > > You should see a resource as an instance of some data object and not > as some process providing access to the data. A resource is a > document, not the process providing access to documents. > > Compare it with a normal web server: > > If you try to access a resource (web page) which is not there, it > returns a 404. > Although the process providing the resource exists (the webserver) the > resource you are after does not (the web page), hence the 404. > > A 404 means the client was able to connect to the server, but the > server was unable to find the information you are looking for. > Its an error made by the client, not by the server. > > > Ralph. > > MedVision360 > >
