3 ms·

SOAP wants you to call procedures and therefore you need a static list of procedures to call. An object, on the other hand, simply responds to messages. If you

SOAP wants you to call procedures and therefore you need a static list of procedures to call. An object, on the other hand, simply responds to messages. If you send it a message it doesn't understand it can respond with something like METHOD_MISSING which nicely translates to HTTP as 404.

route66 15y ago
Yes I want a static list of procedures to call. GET, PUT POST and DELETE are to coarse grained. Method missing is in my book completely differrent from Page Not Found. Method != Resource.
- noblethrasher 15y ago
  404 doesn't mean "Page Not Found". It simple means "Not Found". This isn't pedantry, the result of a request (message) for an object is the representation of the state of that object. 404 is an application level error saying that the remote object has no method for dealing with the message. Obviously that also means it's not going to be able to send you a representation of the state of some object that was the response to the message. Also, REST doesn't preclude having a static list of messages. It's just prescribes that it's up to the remote object to report the messages to which it can respond and up to the local object to decide to statically record those messages somewhere so that it doesn't have to unnecessarily ask again. The remote object can even helpfully tell you when that list of "procedures" might expire so that the local object can know when it should ask again.
  - desas 15y ago
    404 means the requested URI is not found, not "I can't/won't use this method". For "I won't use this method on the resource you specified" you need a 405 For "I do not understand this method" you need a 501.
    - noblethrasher 15y ago
      Well, this is a textbook case of a semantic divide: deciding what the codes should mean for your application. This is similar to figuring out whether NULL should mean "not applicable" or "not known" for a particular database table. Now, I don't really think it's worth arguing and I can certainly see why you would use those codes that way but for me I've always treated 4xx codes as being about the resource/object and 5xx codes as being about the object's environment (i.e. the server). Said another way, I treat 5xx as runtime exceptions and 4xx as application error messages. I'd never write code that returned a 5xx error from within my application for instance, that's for the server to handle. 405 means that the object knows about the method but for some reason won't allow you to call it. In OOP parlance, you would use it if someone tried to call the "Drive()" method without first calling the "StartEngine()" method. Indeed, RFC-2615 prescribes that you return a list of valid methods if you return a 405. Thus, the only real candidates for something like METHOD_MISSING are 400 and 404. But 400 seems like it's for something that the application can't even understand. Like if the client is using some weird encoding in the host headers or something.
javascriptlol 15y ago
Are you saying SOAP won't tell you it doesn't understand if you send a bad message?
- noblethrasher 15y ago
  I didn't mean to say that (but I guess it looks like I did). Obviously there are other ways if singnalling receipt of a bad message (throwing exceptions for instance). METHOD_MISSING seems more natural to me at least. What I meant to say is that in REST, the set of messages to which an object will respond is a function of the object's current state. With SOAP, a URL endpoint always takes the same set of messages (until the code is rewritten or something).
  - javascriptlol 15y ago
    I don't see any reason why SOAP can't support dynamically changing sets of procedure calls. Furthermore, I think that is a bad idea since it will break backward compatibility. No amount of web-buzzwording will get around that problem.
- noblethrasher 15y ago
  > I don't see any reason why SOAP can't support dynamically changing sets of procedure calls. Furthermore, I think that is a bad idea since it will break backward compatibility. No amount of web-buzzwording will get around that problem. Of course enclosing a message in a SOAP envelope does not preclude RESTfulness. If the set of messages to which an object responds is a function of its current state then it's RESTful (or at least lead to a RESTful design).
  - javascriptlol 15y ago
    So what you're admitting is that REST doesn't add any new novelties in terms of being discoverable?
    - noblethrasher 15y ago

route66 15y ago

Yes I want a static list of procedures to call. GET, PUT POST and DELETE are to coarse grained. Method missing is in my book completely differrent from Page Not Found. Method != Resource.

noblethrasher 15y ago
404 doesn't mean "Page Not Found". It simple means "Not Found". This isn't pedantry, the result of a request (message) for an object is the representation of the state of that object. 404 is an application level error saying that the remote object has no method for dealing with the message. Obviously that also means it's not going to be able to send you a representation of the state of some object that was the response to the message. Also, REST doesn't preclude having a static list of messages. It's just prescribes that it's up to the remote object to report the messages to which it can respond and up to the local object to decide to statically record those messages somewhere so that it doesn't have to unnecessarily ask again. The remote object can even helpfully tell you when that list of "procedures" might expire so that the local object can know when it should ask again.
- desas 15y ago
  404 means the requested URI is not found, not "I can't/won't use this method". For "I won't use this method on the resource you specified" you need a 405 For "I do not understand this method" you need a 501.
  - noblethrasher 15y ago
    Well, this is a textbook case of a semantic divide: deciding what the codes should mean for your application. This is similar to figuring out whether NULL should mean "not applicable" or "not known" for a particular database table. Now, I don't really think it's worth arguing and I can certainly see why you would use those codes that way but for me I've always treated 4xx codes as being about the resource/object and 5xx codes as being about the object's environment (i.e. the server). Said another way, I treat 5xx as runtime exceptions and 4xx as application error messages. I'd never write code that returned a 5xx error from within my application for instance, that's for the server to handle. 405 means that the object knows about the method but for some reason won't allow you to call it. In OOP parlance, you would use it if someone tried to call the "Drive()" method without first calling the "StartEngine()" method. Indeed, RFC-2615 prescribes that you return a list of valid methods if you return a 405. Thus, the only real candidates for something like METHOD_MISSING are 400 and 404. But 400 seems like it's for something that the application can't even understand. Like if the client is using some weird encoding in the host headers or something.

javascriptlol 15y ago

Are you saying SOAP won't tell you it doesn't understand if you send a bad message?

noblethrasher 15y ago
I didn't mean to say that (but I guess it looks like I did). Obviously there are other ways if singnalling receipt of a bad message (throwing exceptions for instance). METHOD_MISSING seems more natural to me at least. What I meant to say is that in REST, the set of messages to which an object will respond is a function of the object's current state. With SOAP, a URL endpoint always takes the same set of messages (until the code is rewritten or something).
- javascriptlol 15y ago
  I don't see any reason why SOAP can't support dynamically changing sets of procedure calls. Furthermore, I think that is a bad idea since it will break backward compatibility. No amount of web-buzzwording will get around that problem.
noblethrasher 15y ago
> I don't see any reason why SOAP can't support dynamically changing sets of procedure calls. Furthermore, I think that is a bad idea since it will break backward compatibility. No amount of web-buzzwording will get around that problem. Of course enclosing a message in a SOAP envelope does not preclude RESTfulness. If the set of messages to which an object responds is a function of its current state then it's RESTful (or at least lead to a RESTful design).
- javascriptlol 15y ago
  So what you're admitting is that REST doesn't add any new novelties in terms of being discoverable?
  - noblethrasher 15y ago