SOA in the API World - Facades, Transactions, Stateless Services
Upcoming SlideShare
Loading in...5
×
 

SOA in the API World - Facades, Transactions, Stateless Services

on

  • 5,715 views

 

Statistics

Views

Total Views
5,715
Views on SlideShare
3,325
Embed Views
2,390

Actions

Likes
1
Downloads
62
Comments
1

8 Embeds 2,390

http://www.scoop.it 1918
http://apigee.com 358
https://blog.apigee.com 82
http://edit.apigee.net 15
http://mktg-dev.apigee.com 8
http://edit.mktg.jupiter.apigee.net 6
https://www.google.com 2
http://mktg-new.local 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • <br /><iframe width="350" height="288" src="http://www.youtube.com/embed/C2Y8k5U3epo" frameborder="0"></iframe>
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Creative Commons Attribution-Share Alike 3.0 United States License

SOA in the API World - Facades, Transactions, Stateless Services SOA in the API World - Facades, Transactions, Stateless Services Presentation Transcript

  • SOA in the API World –Facades, Transactions, Stateless Services . . .Apigee@apigeeBrian Pagano@brianpaganoGreg Brail@gbrail
  • groups.google.com/group/api-craft
  • youtube.com/apigee
  • slideshare.net/apigee
  • @brianpaganoBrian Pagano@gbrailGreg Brail
  • SOA’s Adventures in API-Land - RecapServices? I’ve got services! (Designing a Façade)Layers: Separation of Responsibility (which Transactions?)Do I make my services stateless?How to design internal APIs?Overview
  • Previously onSOA’s Adventures inAPI-Land…
  • Let’s make sure we’re all talking about the same thing.And let’s only talk about the core principles of SOA, notthe cruft that vendors have added on.Some product features have started to be thought of asnecessary for SOA.SOA recap
  • But SOA is about Service Oriented Architecture.Services are good.This taps into the deeper philosophy of breakingdown problems into components.Components are good.
  • A service oriented architecture might include,but does not require:• Heavyweight contracts• Service registries• Dynamic discoveryThese are product “features”.
  • Services? I’ve GotServices
  • You’ve got servicesNow you need to design a Facade
  • Avoid the forklift anti-pattern
  • What are your service consumers using?(Customers, partners, …)
  • What are your company goals for this API?revenue, reach, holding market share, re-using existing assets
  • Design a single, RESTful façade that looksoutside-inDon’t expose implementation complexity
  • Transformation OnboardingProtocol MediationBigSystemDBContentManagement SOAP JDBCAppAppDeveloperXMLRouting Authentication Traffic Mgmt Caching MonitoringAPI Facade
  • Be consistent
  • Do what developers are expecting.
  • Layers:Separation of Responsibility
  • What types of things should a proxy do?
  • What types of things would you not wantto do in a proxy?
  • Do I Make My ServicesStateless?
  • Yes. Make your services stateless.Unless you have a good reason not to.
  • But, what do we mean by “stateless”?State can be either data entity state or session/activitystate.
  • A stateless service never holds data or business domainstate.A stateless service minimizes holding any activity orprocessing state information. (Session data is especiallybad)
  • Consider a shopping cart:A. The client maintains the state and sends the whole thingback and forth every timeor:B. The server maintains the cart in memory via a temporary“session ID”, and the server empties the cart after someinactivityor:B. The server maintains the cart in a database via a permanent“shopping cart ID”
  • Plan A: Requiring the client to maintain all state – isimpracticalPlan C : Storing the state in a database – gives thedeveloper what they expect, and gives businessbenefits tooButPlan B: A “session” – was popular in the Web 1.0 erabut is unnecessary in today’s world of scalable andavailable databases
  • How To DesignInternal APIs
  • NoAre Internal APIs Just SOA?
  • Internal APIs are APIs which are not exposed tothe outside world.SOA is SOALet’s keep these things straight.
  • Design internal APIs with the same level ofconsumability as you would an externally-facing API.
  • Why should you use APIs rather than SOA as themodel for your internal services? You will want to use the same services for both mobile appsand your web apps You don’t know what kinds of device technology your API willneed to support in the future You don’t know what kinds of web app technology yourdevelopers will want to use in the future You do know that it will all change and you will have to adaptquickly
  • Down the road, who knows . . .What does “internal” mean anyway?Besides, you might use them again for adifferent audience.
  • In SumSOA still has uses in the API worldAn API layer is critical to meet today’s businessdemandsSometimes they work well togetherExpose functionality, not systems orimplementation complexity
  • Questions
  • groups.google.com/group/api-craft
  • THANK YOUQuestions and ideas to:@brianpagano@gbrailgroups.google.com/group/api-craft