|
|
|
|
|
|
by WilliamLP
5997 days ago
|
|
|
> you'll implement this method and allow your users to invoke it via http://myservice.com/employee/simpson That's fine of course for the trivial example, but what if my third parameter is an array, and I want to see a sensible error if I pass a hash table? What are the rules for which parameters go in the URL, whether they are delimited by ".", "/", or something else, and when they come as JSON in the request body, and how many there are, and what format they should come in? > find a library (or implement your own) that will generate all the needed XML files etc. Is this a problem? Many many such libraries exist which make exposing RPC calls nearly as easy as writing function declarations. (After all, that's what it's for - remote functions.) When I'm writing normal functions, I don't pass a request type, and a parameter string with various arbitrary delimiters, along with a possible big blob of text, and use that to fit every possible function, dealing with it in my own individual ad hoc way, do I? |
|
|
regarding question 1: I think it's all a question of how your method behaves -- or how it is implemented. if your method requires JSON, then you'll have to feed it JSON. if your method requires 2 parameters, then you'll have to give it 2 parameters (e.g. myservice.com/?param1=123¶m2=456).
regarding question 2: no, it's definitely not a problem, until the library is not maintained anymore or god knows what else. well, yes, it's more intuitive to write a plain simple function then to construct a very complicated request string as you mentioned.
as I already stated above, I don't have enough experience with REST at the moment to give you a more precise response, so I hope this one suffices. I also hope that somebody here on HN with more experience in the REST field will answer your question more precisely, so I can learn a thing or two, too :)