-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vikas Banjara wrote: > Hi all, > > I will try to write a flow of steps for the use case. Please correct me > wherever I am wrong.
Hi Vikas, I will answer inline and as approprite update the Wiki in parallel. It was suggested that we need to be more wordy when describing the user stories. What is your opinion? Can you understand what the user wants to do? Would a more detailed description help to understand better? One important thing I did not mention yet is that we should always keep in mind that the "user" we are talking about can also be a "user agent". This means it can well be a machine! This is important to keep in mind. Especially the more complex issues regarding monitoring, usage of RSS and anything that can be automized will be highly relevant for machine to machine communication. More answers to your questions inline. All cases that I do not comment I assume that we are thinking along the same lines. > On Tue, Jun 1, 2010 at 10:26 PM, Arnulf Christl < > [email protected]> wrote: > > Hi Vikash, > here goes the first try for a user story: > > User finds a new service / creates a new service and wants to publish > it. All that is needed to register a new service is a user name > (authentication) with email for confirmation, the Capabilities URL of > the service and whether it should be public. > > >> First the user needs to authenticate himself using a username/password. For >> this I am working on plain http authentication with the mapbender server. For a start that is OK. Later we might want to look into how we can make the authentication more persistant (see also: user agent / machine scenario). >> The registering of a new service is a Create operation. So, it should be a >> POST operation. And the URI should be like this (assuming that the url of >> the mapbender server is www.mapbender.org) - >> http://www.mapbender.org/resources/resourceID > >> So to post this user would send four parameters username, email id and >> capabilities url and public/private status of the service. > > > > Q: What happens if this URL (or a similar one?) has already been > uploaded earlier? Add a counter for the the same URL (uploaded several > times)? > A: The Capabilities URL needs to be checked against the ones already in > the database. -> What happens then? > > >> In case, the capabilities URL already exists, we can send an error to the >> user saying that it already exists. The response (artefact: "Representation returned to the client") should include option of how to continue processing. That could be the link to the existing resource and maybe one to the "Update" REST interface. > Q: What happens if the user gets "lost", is deleted, etc.? > A: ? A user can be deleted from the Mapbender database. What happens to the "owner" of the resource in that case? We could trigger an SQL cascade DELETE on the database but in my opinion it would be nicer to keep resource URL even if the owner disappears. We could introduce a garbage or public user for those cases but then must take care that we do not get mixed up with permissions and the security proxy. >> I didn't really get this? > > > Q: What happens if the service is deleted by another user? (This is > currently not possible, it would generate an error message). > > > > > Q: What happens if Mapbender cannot read the capabilities document? > A: Error message & ? > > > >> Again can you explain me this? An example might help: This URL delivers an OGC WMS Capabilities Document that Mapbender can parse and store in the database: http://demowms.fossgis.de/wms/simple?SERVICE=WMS&REQUEST=GetCapabilities (even although the URL misses the parameter VERSION=x.x.x) This URL on the other hand does not deliver an OGC WMS Capabilities Document that Mapbender can parse: http://gdz.bkg.bund.de/wms_dtk25&v_service=wms&response_xml=wms_dtk25 In my opinion it (should) return a 401 or 403 but instead sends a 200 (OK) and then says in the XML that it returns that it is not OK. We will have lots of confusing response codes but should therefore still not ignore them but make as best use of them as we can. Find more examples of working OGC WMS URLs from this page: http://www.mapbender.org/Test Please add to this list when you find an interesting or "strange" OGC service. > Q: Are we going to use this "interface" also to update services or do we > need to create another one? > A: ? > > >> To update the service we need to create a separate interface. And that would >> be using PUT HTTP command. Yes. This "interface" (or is it not rather a resource too?) should be included in the response to a request that wants to create a resource that already exists. Best regads, Arnulf > We add these User Stories to the Wiki so that we can refine them there: > http://www.mapbender.org/Talk:RESTful_API > > > Best regads, > Arnulf. > > > > > _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev >> > ------------------------------------------------------------------------ > _______________________________________________ > Mapbender_dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapbender_dev - -- Arnulf Christl Exploring Space, Time and Mind http://arnulf.us -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwI+pgACgkQXmFKW+BJ1b1f/QCdHo3nhNjsyHz5zL7NTex4V0Of EpYAmwT9+AN+PRg1maCj82wRaZvSqUPj =x4Hb -----END PGP SIGNATURE----- _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
