�ݺ�ߣshows by User: bobdobbes

�ݺ�ߣshows by User: bobdobbes / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: bobdobbes / Mon, 18 Sep 2017 03:24:45 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: bobdobbes Api pattern /slideshow/api-pattern/79875804 apipattern-170918032445
The old API Pattern was designed in the 70's for centralized architectures and binds it's communication logic to it's business logic so that I/O cannot be shared with other services in an architecture without duplication. We will show a new API Pattern that fixes this issues by abstraction the communication layer away from business logic thus enabling sharing of I/O, better scale, less code, and faster processing as well as many other things.]]>
The old API Pattern was designed in the 70's for centralized architectures and binds it's communication logic to it's business logic so that I/O cannot be shared with other services in an architecture without duplication. We will show a new API Pattern that fixes this issues by abstraction the communication layer away from business logic thus enabling sharing of I/O, better scale, less code, and faster processing as well as many other things.]]> Mon, 18 Sep 2017 03:24:45 GMT /slideshow/api-pattern/79875804 bobdobbes@slideshare.net(bobdobbes) Api pattern bobdobbes The old API Pattern was designed in the 70's for centralized architectures and binds it's communication logic to it's business logic so that I/O cannot be shared with other services in an architecture without duplication. We will show a new API Pattern that fixes this issues by abstraction the communication layer away from business logic thus enabling sharing of I/O, better scale, less code, and faster processing as well as many other things. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/apipattern-170918032445-thumbnail.jpg?width=120&height=120&fit=bounds" /> The old API Pattern was designed in the 70's for centralized architectures and binds it's communication logic to it's business logic so that I/O cannot be shared with other services in an architecture without duplication. We will show a new API Pattern that fixes this issues by abstraction the communication layer away from business logic thus enabling sharing of I/O, better scale, less code, and faster processing as well as many other things.

Api pattern from Owen Rubel

]]> 9365 0 https://cdn.slidesharecdn.com/ss_thumbnails/apipattern-170918032445-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Api chaining(tm) /slideshow/api-chainingtm/79773902 apichaining-170914144558
Talk from RestFest on how API Chaining(tm) works in chaining multiple api calls with one request and response without redirects.]]>
Talk from RestFest on how API Chaining(tm) works in chaining multiple api calls with one request and response without redirects.]]> Thu, 14 Sep 2017 14:45:58 GMT /slideshow/api-chainingtm/79773902 bobdobbes@slideshare.net(bobdobbes) Api chaining(tm) bobdobbes Talk from RestFest on how API Chaining(tm) works in chaining multiple api calls with one request and response without redirects. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/apichaining-170914144558-thumbnail.jpg?width=120&height=120&fit=bounds" /> Talk from RestFest on how API Chaining(tm) works in chaining multiple api calls with one request and response without redirects.

Api chaining(tm) from Owen Rubel

]]> 3276 4 https://cdn.slidesharecdn.com/ss_thumbnails/apichaining-170914144558-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 BeAPI API Framework /bobdobbes/beapi-api-framework iot-170912154844
This is a brief demo of the BeAPI Framework on IOT devices in comparison to other offerings currently being used.]]>
This is a brief demo of the BeAPI Framework on IOT devices in comparison to other offerings currently being used.]]> Tue, 12 Sep 2017 15:48:44 GMT /bobdobbes/beapi-api-framework bobdobbes@slideshare.net(bobdobbes) BeAPI API Framework bobdobbes This is a brief demo of the BeAPI Framework on IOT devices in comparison to other offerings currently being used. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/iot-170912154844-thumbnail.jpg?width=120&height=120&fit=bounds" /> This is a brief demo of the BeAPI Framework on IOT devices in comparison to other offerings currently being used.

BeAPI API Framework from Owen Rubel

]]> 453 0 https://cdn.slidesharecdn.com/ss_thumbnails/iot-170912154844-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Apiworld /slideshow/apiworld2-redux/69841140 apiworld2redux-161205164230
The API pattern was created in the 1970's when 'distributed architectures' didn't even exist and was established mainly for 'centralized architectures' as it bound the communication data/logic to the business logic. In a modern world, we have moved to distributed architectures where we now have to share the I/O... but that communication logic still remains bound in the application due to an old API pattern. This makes it so that the IO data and functionality related to a request/response cannot be shared with our edge services without duplication/entanglement. This in turn means the data/functionality in our services then cannot be synchronized. This leads to dropped threads, poor security, bad data, bad user experience, broken application, etc. This can ALL be fixed and improved and even lead to better speed, scalability and automation through a new API Pattern. ]]>
The API pattern was created in the 1970's when 'distributed architectures' didn't even exist and was established mainly for 'centralized architectures' as it bound the communication data/logic to the business logic. In a modern world, we have moved to distributed architectures where we now have to share the I/O... but that communication logic still remains bound in the application due to an old API pattern. This makes it so that the IO data and functionality related to a request/response cannot be shared with our edge services without duplication/entanglement. This in turn means the data/functionality in our services then cannot be synchronized. This leads to dropped threads, poor security, bad data, bad user experience, broken application, etc. This can ALL be fixed and improved and even lead to better speed, scalability and automation through a new API Pattern. ]]> Mon, 05 Dec 2016 16:42:30 GMT /slideshow/apiworld2-redux/69841140 bobdobbes@slideshare.net(bobdobbes) Apiworld bobdobbes The API pattern was created in the 1970's when 'distributed architectures' didn't even exist and was established mainly for 'centralized architectures' as it bound the communication data/logic to the business logic. In a modern world, we have moved to distributed architectures where we now have to share the I/O... but that communication logic still remains bound in the application due to an old API pattern. This makes it so that the IO data and functionality related to a request/response cannot be shared with our edge services without duplication/entanglement. This in turn means the data/functionality in our services then cannot be synchronized. This leads to dropped threads, poor security, bad data, bad user experience, broken application, etc. This can ALL be fixed and improved and even lead to better speed, scalability and automation through a new API Pattern. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/apiworld2redux-161205164230-thumbnail.jpg?width=120&height=120&fit=bounds" /> The API pattern was created in the 1970's when 'distributed architectures' didn't even exist and was established mainly for 'centralized architectures' as it bound the communication data/logic to the business logic. In a modern world, we have moved to distributed architectures where we now have to share the I/O... but that communication logic still remains bound in the application due to an old API pattern. This makes it so that the IO data and functionality related to a request/response cannot be shared with our edge services without duplication/entanglement. This in turn means the data/functionality in our services then cannot be synchronized. This leads to dropped threads, poor security, bad data, bad user experience, broken application, etc. This can ALL be fixed and improved and even lead to better speed, scalability and automation through a new API Pattern.

Apiworld from Owen Rubel

]]> 966 6 https://cdn.slidesharecdn.com/ss_thumbnails/apiworld2redux-161205164230-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 IO State In Distributed API Architecture /slideshow/io-state-in-distributed-api-architecture/52948393 iostateindistributedarch-150918202648-lva1-app6892
The API pattern bind IO functionality to business functionality by binding IO state either through annotation (ie JAX) or by extending a RestfulController. As a result, the data associated IO State cannot be shared with the architectural instances because it is bound to the controller. This creates architectural cross cutting concerns not only with the functionality but also with the data. By abstracting the functionality, we can create a versioned data object for IO state that can be shared,cached,synced,reloaded on the fly for all architectural instances without having to restart any instance. This greatly improve automation, performance and flow of api applications and architecture.]]>
The API pattern bind IO functionality to business functionality by binding IO state either through annotation (ie JAX) or by extending a RestfulController. As a result, the data associated IO State cannot be shared with the architectural instances because it is bound to the controller. This creates architectural cross cutting concerns not only with the functionality but also with the data. By abstracting the functionality, we can create a versioned data object for IO state that can be shared,cached,synced,reloaded on the fly for all architectural instances without having to restart any instance. This greatly improve automation, performance and flow of api applications and architecture.]]> Fri, 18 Sep 2015 20:26:48 GMT /slideshow/io-state-in-distributed-api-architecture/52948393 bobdobbes@slideshare.net(bobdobbes) IO State In Distributed API Architecture bobdobbes The API pattern bind IO functionality to business functionality by binding IO state either through annotation (ie JAX) or by extending a RestfulController. As a result, the data associated IO State cannot be shared with the architectural instances because it is bound to the controller. This creates architectural cross cutting concerns not only with the functionality but also with the data. By abstracting the functionality, we can create a versioned data object for IO state that can be shared,cached,synced,reloaded on the fly for all architectural instances without having to restart any instance. This greatly improve automation, performance and flow of api applications and architecture. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/iostateindistributedarch-150918202648-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds" /> The API pattern bind IO functionality to business functionality by binding IO state either through annotation (ie JAX) or by extending a RestfulController. As a result, the data associated IO State cannot be shared with the architectural instances because it is bound to the controller. This creates architectural cross cutting concerns not only with the functionality but also with the data. By abstracting the functionality, we can create a versioned data object for IO state that can be shared,cached,synced,reloaded on the fly for all architectural instances without having to restart any instance. This greatly improve automation, performance and flow of api applications and architecture.

IO State In Distributed API Architecture from Owen Rubel

]]> 3565 0 https://cdn.slidesharecdn.com/ss_thumbnails/iostateindistributedarch-150918202648-lva1-app6892-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Api Abstraction & Api Chaining /bobdobbes/api-abstraction-api-chaining springone2gx2014-140911190930-phpapp01
API abstraction is the separation of cross cutting concerns related to the api to better enable externalization to architectural concerns. Not only does this enable easier externalization, synchronization and sharing of the environment with external architecture but this also enables us to reload the api configuration on the fly, have DRY'r code, easier batching, api chaining, reduced code, synchronized configuration/security, reduced throughput and much more. Video Available here : http://java.dzone.com/articles/springone2gx-2014-replay-api ]]>
API abstraction is the separation of cross cutting concerns related to the api to better enable externalization to architectural concerns. Not only does this enable easier externalization, synchronization and sharing of the environment with external architecture but this also enables us to reload the api configuration on the fly, have DRY'r code, easier batching, api chaining, reduced code, synchronized configuration/security, reduced throughput and much more. Video Available here : http://java.dzone.com/articles/springone2gx-2014-replay-api ]]> Thu, 11 Sep 2014 19:09:30 GMT /bobdobbes/api-abstraction-api-chaining bobdobbes@slideshare.net(bobdobbes) Api Abstraction & Api Chaining bobdobbes API abstraction is the separation of cross cutting concerns related to the api to better enable externalization to architectural concerns. Not only does this enable easier externalization, synchronization and sharing of the environment with external architecture but this also enables us to reload the api configuration on the fly, have DRY'r code, easier batching, api chaining, reduced code, synchronized configuration/security, reduced throughput and much more. Video Available here : http://java.dzone.com/articles/springone2gx-2014-replay-api <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/springone2gx2014-140911190930-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds" /> API abstraction is the separation of cross cutting concerns related to the api to better enable externalization to architectural concerns. Not only does this enable easier externalization, synchronization and sharing of the environment with external architecture but this also enables us to reload the api configuration on the fly, have DRY'r code, easier batching, api chaining, reduced code, synchronized configuration/security, reduced throughput and much more. Video Available here : http://java.dzone.com/articles/springone2gx-2014-replay-api

Api Abstraction & Api Chaining from Owen Rubel

]]> 10693 0 https://cdn.slidesharecdn.com/ss_thumbnails/springone2gx2014-140911190930-phpapp01-thumbnail.jpg?width=120&height=120&fit=bounds presentation White http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-bobdobbes-48x48.jpg?cb=1732458435 One of the original team members of Amazon from 95-98, rewrote the API pattern for distributed architectures, creator of API Chaining(tm)/shared IO State/API abstraction. Respected leader in API development speaking at API World, API Days, Spring One, Univ of Berkeley, Univ of Washington and others. If you are looking for a leader in distributed architectures, microservices and API's, look no further. www.beapi.io https://cdn.slidesharecdn.com/ss_thumbnails/apipattern-170918032445-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/api-pattern/79875804 Api pattern https://cdn.slidesharecdn.com/ss_thumbnails/apichaining-170914144558-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/api-chainingtm/79773902 Api chaining(tm) https://cdn.slidesharecdn.com/ss_thumbnails/iot-170912154844-thumbnail.jpg?width=320&height=320&fit=bounds bobdobbes/beapi-api-framework BeAPI API Framework