RESTFul architecture re-imagines Web Service integration in a more http-oriented way. This kindled interest in the API designers & practitioners to fill in some gaps in standards-based metadata overload, security and client integration.
In RESTful Architecture, objects are modelled as resources (actors) as opposed to verbs/actions. It is typical in this mode of communication for the client to access and explore a resource before editing/modifying the data. For example, one GETs a user by searching with the id or name. Checks the address and modifies a field let's say street and PUTs. While the objects depend on the application/business/domain, the http actions are universal! Clients don't need to refer to getUser, editUser or deleteUser separately. Add attachment handling, header management, content type management, caching and metadata handling to this, it is a great recipe of APIs. No wonder most services are at peace (RESTful) these days.
The ease of REST services aligned naturally with the integration to web layers because of it's closeness to HTTP.
Anyone thinking swagger or apiary?
All Web Service / API Developers run into a common problem.
How granular should my service be? Do I have a mammoth service that does every possible activity at just 1 end-point? Or... do I do finely grained single responsibility super-responsive services that I can tie up as needed?
Continued in the next part...
(Please let me know your feedback in the comments.)
In RESTful Architecture, objects are modelled as resources (actors) as opposed to verbs/actions. It is typical in this mode of communication for the client to access and explore a resource before editing/modifying the data. For example, one GETs a user by searching with the id or name. Checks the address and modifies a field let's say street and PUTs. While the objects depend on the application/business/domain, the http actions are universal! Clients don't need to refer to getUser, editUser or deleteUser separately. Add attachment handling, header management, content type management, caching and metadata handling to this, it is a great recipe of APIs. No wonder most services are at peace (RESTful) these days.
The ease of REST services aligned naturally with the integration to web layers because of it's closeness to HTTP.
Anyone thinking swagger or apiary?
All Web Service / API Developers run into a common problem.
How granular should my service be? Do I have a mammoth service that does every possible activity at just 1 end-point? Or... do I do finely grained single responsibility super-responsive services that I can tie up as needed?
Continued in the next part...
(Please let me know your feedback in the comments.)
