dotnetomaniak.pl - Jak nie budować API – na przykładzie SPClaimProvider

Witaj Maniaku , Zaloguj sięlub Zarejestruj

Strona główna
Kategorie
- Architektura
  Rozwiązania na wyższym poziomie abstrakcji. Wzorce, dobre praktyki i pomysły.
- Bazy danych i XML
  MSSQL, Oracle, mySQL, PostgreSQL. ORMy i nie tylko
- Cloud
  Rozwiązania chmurowe - Azure, AWS i inne
- Daj się poznać 2016
  Artykuły w ramach konkursu Daj się poznać
- Daj się poznać 2017
  Artykuły w ramach konkursu Daj się poznać - edycja 2017
- Inne
  Pozostałe nigdzie indziej niesklasyfikowane artykuły
- Mobile development
  WP7, WindowsMobile, WindowsCE ale także inne platformy mobilne
- Narzędzia
  Przydatne narzędzia dla każdego
- Office
  Sharepoint i wszystko co związane z programowaniem na tę platformę
- Programowanie rozproszone
  Wszystko co związane z rozwojem aplikacji przystosowanych do obsługi więcej niż 1 maszyny
- Silverlight
  Rich Internet Applications od MS. Wszelkie wersje i dodatki.
- Sztuka programowania
  Przykłady ładnego kodu, wpisy o tym jak pisać kod aby był czymś więcej niż zlepkiem znaków
- Web
  Web Forms, MVC, jQuery i inne przydatne rzeczy dla każdego siedzącego w Web Development
- Windows
  WinForms, WPF, kontrolki i wszystko inne związane z programowaniem na platformę Windows
O dotNETomaniaku
Sklep z gadżetami

Podbij ↑

Jak nie budować API – na przykładzie SPClaimProvider | Maciej Aniserowicz o programowaniu

Miałem ostatnio okazję implementować własny provider claimów do SharePointa. Jak prawie całe API SharePointa, ta kupa kupy woła o pomstę do nieba. Postanowiłem wykorzystać okazję i zaprezentować jak to złe API mogłoby wyglądać, gdyby ktoś w teamie odpowiedzialnym za “dev-experience” tego kolosa miał trochę oleju w głowie. Ale najpierw kilka słów wprowadzenia, czyli przedstawienie problemu.

Tagi: API, best practices, SharePoint

Źródło: www.maciejaniserowicz.com

Dziel się z innymi: