41–50 of 124 posts
I generally use a pattern like: GET /api/resource POST /api/resource/action Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.
This is my approach as well. Works very well with an event-sourcing model. It is much easier to capture user intent with POST /api/customer/1/change-address-due-to-move { "address_1": "...", "address_2": "...", ... } than with: PUT /api/customer/1 { "address_1": "...", "address_2": "...", ... } Also, GET /api/resource/action is nice place for a payload describing the expected inputs to the action. Link it all togethe…
I prefer to call my APIs RESTish. That way, I can avoid never ending debates about whether some particular feature of my API conforms to REST.
Who would have thought that there's more than one way to skin a cat? Or maybe REST is the best chuck out the rest! Pun intended! I like your approach because it avoids never ending debates.
This to me is like arguing that object-oriented programming isn't really any better than procedural programming because I know how to write well-structured procedural programs. This is completely beside the point, which is that procedural programming as a style tends toward balls-of-mud programs (to simplify things), and object-oriented techniques were conceived of in order to address the characteristics of procedural programming that are the cause of this tendency.
I view RESTful API programming in a similar vein: RPC also has negative tendencies (such as the creation of fragile protocols), and REST addresses many, if not all of those. Most of the time for more people, RESTful techniques will lead to better service and API design than will RPC, just like for most of the people most of the time, object-oriented programming will lead to better programs than will procedural programming.
POST /users/create
POST /users/1234/read
POST /users/1234/update
POST /users/1234/delete
POST /new_address_due_to_move.php?customer_id=1234,
Earlier quoted context omitted.
> REST deals with things (like OO), RPC deals with actions (like functional). I think it's the opposite: REST deals with data, while RPC calls an operation that has side effects on some (potentially) unknown state. Not arguing that one is better just offering my thoughts on the analogy.
That looks to me like you both agree. Things==data and actions == "calls an operation"
I started developing network apps before REST existed -- probably like many people here, that wasn't long ago, SOAP, various things like RMI and then XMLRPC were things. SOAP was never good anyway, deeply buried in standards committee goo. But there are still things I miss from these things. When I found XMLRPC after doing all these things, it was very much a "WOW" moment. (JSON of course, with it's definite differen…
But I really like the idea that the API can tell you about the API, and do kind of wish JSON REST APIs had similar patterns.
I think the main problem that XML runs into is that it's used a data interchange format and/or a data serialization, instead of a markup.
I think the bit you're missing from the XML APIs - that makes you re-implement things - is the lack of an API descriptive document (like the WSDL). If that was a thing, REST is at least as automatically ported as any XML API style. (Someone would still have to write the libraries that turn the document into objects/functions, but that happens with the XML stuff as well)
Earlier quoted context omitted.
> REST deals with things (like OO), RPC deals with actions (like functional). I think it's the opposite: REST deals with data, while RPC calls an operation that has side effects on some (potentially) unknown state. Not arguing that one is better just offering my thoughts on the analogy.
That looks to me like you both agree. Things==data and actions == "calls an operation"