SOA / Web Services / Java

A Technology Blog

Archive for the ‘API’ Category

SOA Services/ Web Services Vs APIs

Posted by Vivek on May 8, 2016

With a lot of emphasis of building APIs, web services have taken a back seat but it certainly does not mean that APIs can completely replace the conventional web services within an SOA environment. However, with the rapid technological advances and changing business requirements, most of the implementations have become API-centric. This post just highlights some of the key differences and draw a line between the two.

1. Mostly used internally by organizations or partners whereas APIs are mostly built for external consumers. APIs are seen as a way to unlock new revenue streams by creating a marketplace.

2. SOA services are mainly need based and are driven by existing IT or Business demands. APIs are developed keeping the future needs in mind and are key enabler for mobile and web based applications. SOA or webservices are suitable candidates in an event driven architecture.

3. SOA services are standard based and all standards have reached a certain level of maturity and are adopted by industries. APIs are often not standard based. There is no mandate to create a contract unlike that of WSDL in SOA.

4. Security is a key challenge when using APIs as most of them are exposed to the outside world. Most of the SOA Services are behind firewall and are within DMZs.

5. Scaling is another aspect to look at when using APIs. With an increase in the number of consumers, appropriate controls have to be in place for scaling in and scaling out APIs. For SOA services, it is easier to predict the volume of requests as they are driven by the internal business needs. A private API can be considered closer to SOA services.

6. APIs are mostly finely-grained to make them more reusable. Granurality in SOA Services can be coarse and is designed to make them reusable as well as composable.

7. API protyping tools like Apiary, Swagger etc help in rapidly developing interfaces and are easy to use. This is not always the case when you are designing services for SOA.

8. Services in SOA are well-equipped to handle complex integration challenges posed by different message formats, transport protocols and semantic standards. Almost all APIs are designed to communicate only using HTTP(S) protocols but the scenario is changing fast with the proliferation of Intenet of Things and the need for more asynchronous communication.

 

 

 

Advertisements

Posted in API, SOA | Leave a Comment »

10 REST Best Practices

Posted by Vivek on May 7, 2016

1. Use uniform contracts to allow consumers to comply with the service requirements, make the service discoverable, loosely coupled and composable.

2. Use POST when you want to create a sub resource. Use POST when you want to update the state of a resource. PUT ensures that a resource or resource value remains unique while duplicate instances are possible when using POST.

3. Use DELETE when you no longer require the resource.

4. When using GET, consider caching the static data in the response. Request should not contain more than 4KB data as it may lead to “414 – Request_URI Too Long” error.

5. Endpoint URI may undergo changes. Use the native HTTP endpoint redirection capability to redirect a request to new URI. HTTp provides status codes such as 301 for “Moved Permanently” and 307 for “Temporary Redirect”

6. Choose the right granularity. A coarse grained service is not always reusable. At the same time, a finer grained service may not be good from performance perspective.

7. When defining URIs,
– use nouns
– use tokens (eg bearer) for authorization/ authentications
– keep the URIs short
– avoid using content type to retain abstraction
– use positional parameters in the query string.

8. A service should be backward compatible.

9. Standard Media types should be clearly specified in the contract. Client should provide valid formats in the “Accept”, “Accept-Language”, “Accept-Charset”, “Accept-Encoding” and “Content-Type” to avoid any interoperability issues. Let the server tell the client if a format is not supported using valid HTTP Code.

10. Use reliable messaging techniques like MQ for critical operations when a message lost due to network failure is unacceptable and message should be retried. While the retry mechanism can be implemented using REST, it should not become complex.

Posted in API, REST, SOA | Leave a Comment »