Transitioning to Hypermedia APIs
For Public Consumption
- Availity - Healthcare
- Clearinghouse between Providers and Payers
Adopted an API first approach
- Avoid duplication of services
- Quickly develop new applications
- Work with partners
Make core APIs available for 3rd parties
- Requires standards and consistency
- And other challenges
Which Brings Challenges
- Talk about how we dealt with challenges
Maintain Consistency Across APIs
Pagination, Filtering, and Sorting
Custom REST API Framework
- Base service and resource classes
- Enforce types services return
- Collections vs Single resources
Standard Media Types
- Support JSON and XML, defaults to JSON
- Provide extensions to return other representations
Controls Types Returned By Methods
- GET Collections
- Others Single resources
- DELETE no body
HTTP Status Codes
- final classes with out supported status codes
- provides guidance on when to use which code
- provide lots of examles
Verification of Resources
- Custom Service
- Reads metadata to discover services
- Ensure conform to naming standards and proper casing
REST Maturity Level
http://martinfowler.com/articles/richardsonMaturityModel.html
- Were Level 1.5
- HTTP Verbs were supported but not used correctly
- Only 200's, 404, or 500 were supported
Introduced HAL-like format
- Baby Steps
- Introduced to support paginations and self links
- Eventually began adding context links
- TODO: Looking for richer linking support for extra metadata, possible support for elasticSearch type queries
Transitioned To More Expressive HTTP Status Codes
- Became more expressive
- Convey more descriptive context so client doesn't need to parse error message for status code.
- Now at Level 3
Swagger - For Definition, CodeGen, and Documentation
Richer Link Relations and Embedded Resources
Transitioning to Hypermedia APIs
For Public Consumption
Availity - Healthcare
Clearinghouse between Providers and Payers