I have just been reading the article RESTify Day Trader this has a small amount of constructing URI's this is also covered here and in more depth in How_to_create_a_REST_Protocol. The process strikes me as very similar to the one I am undergoing in converting the statement of requirements into a design. By hunting for the nouns and verbs and using these as the basis for creation. These links could also be of interest since I am considering using JSON . In the far future this article on using Etags to avoid transmitting the same information again and again are of interest.
Back on my main topic about implementing REST is this article. Areas I will be looking at is the use of accept to return different formats, this may be necessary or of interest for different clients. Various article mention that REST should be stateless and this is fine since retrieving a booking for a certain time and date should return the same data as long as it hasn't been deleted. Accessing an account customer or an employer would have the same effect. However there seems to be a small variation on ideas regarding logging on. For my system it needs to be implemented since the web interface is not for anyone to use. Certain people will have access to different functions. Other people should be forbidden to access anything. It makes no sense for a person in Australia to book a taxi in England. So there needs to be a log on system to check if the user is permitted to carry out that action.
How should this be implemented. Should the query section of the URI always carry a user reference that can be checked by the server. Should this be included in the URI e.g. Ref34253/Bookings instead of /Bookings? or some other scheme? I still need to do some searching.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment