4 ms·
Yes, ok, you will use WebSockets for your API. But what will it look like to book a ticket on your API? "{'action': 'book', 'from': 'Chicago', 'to': 'Moscow'}"?
by k_bx 15y ago
Yes, ok, you will use WebSockets for your API. But what will it look like to book a ticket on your API? "{'action': 'book', 'from': 'Chicago', 'to': 'Moscow'}"? It's still junk without REST style.
The point of REST is operating with resources as building bricks of your API, and using only four CRUD operations on them (or on their collection). Besides, for testing purposes it is good to still have REST API to test it with curl or some web client in your code.
So what I'd suggest is to continue building REST API, but create a smooth REST2WebSocket layer to make your REST requests through WebSockets. Like "{'method': 'PUT', 'resource': '/api/users/john', 'data': '\{\'name\': \'Paul\'...".
- k_bx 15y ago(maybe the examples I provided are not ugly enough to show difference, so I'll try to do that here) On non-rest API you can get in trouble mixing actions and resources, so you can get things like {'action': 'list_users'}, {'action': 'rename_user'}, {'action': 'user_ban'}, {'action': 'rename_user_and_email'}, {'action': 'list_active_users'} While on REST API you are at least consistent that user-resource is /users/, that concrete user is /users/<user_id> and that only operations are CRUD on either all users -> /users/ or on concrete user /users/<user_id>. That gives so much more clarity (+ caching reads, + only open transactions on POST/PUT/DELETE).